You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(20) |
Aug
(8) |
Sep
(12) |
Oct
(5) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Vivek P. <vpt...@gm...> - 2012-07-08 22:22:31
|
subscibe |
From: tm j. <tm...@ya...> - 2011-02-26 15:19:39
|
http://eventostigre.com.ar/bmi3.html |
From: tm j. <tm...@ya...> - 2011-02-25 05:41:27
|
http://redablog.it/bmi2.html |
From: Ted H. <hu...@ap...> - 2006-10-18 11:45:23
|
Today, I added code that will create a service dynamically if the appropriate service template and iBATIS statement is available. Now that we have a working "Struts on Rails" strategy in place, I can get back to actually building the application. -T. |
From: Ted H. <hu...@ap...> - 2006-10-17 11:53:18
|
So, I've been working on a "Struts on Rails" setup that utilizes convention over configuration. In a model 1 JSP, we can do things like run a SQL query on a page to populate a control on the page. This is handy, but hard to maintain over time. In a model 2 architecture, we push the SQL queries back into some type of service that the Action class manages, and then place the result of the query in memory, where the control on the page can find it. In practice, with larger applications, model 2 architecture is easier to maintain over time, but it means writing a lot of glue code. An alternative to glue code is to use "glue conventions". If we are strict with our naming conventions, we can tell the framework that if the control is named "TypeIdList", and there are no other instructions, then run the "TypeIdList" database query and put the result into memory under the name "TypeIdList". If we put the control on its own page, we can arrange it so that the "TypeIdList" action invokes the "TypeIdList" service and returns the TypeIdList page. In practice, for many controls and transactions, we can write the page and write the query, and that's it. The naming conventions can glue the rest together. Here's an example. Input page: [#ftl/] <html> <head> <title>Submit Article</title> </head> <body> [@s.actionerror /] [@s.form action="StorySave_"] [@s.hidden name="story_id" /] [@s.action name="StoryTypeIdList_input" executeResult="true" /] [@s.textfield name="photo_count" label="Number of Photos" /] [@s.textfield name="headline" label="Headline" /] [@s.textfield name="body" label="Body" /] [@s.submit /] [/@s.form] </body> </html> This page has an embedded control, StoryTypeIdList [#ftl/] [@s.select label="Story Type" headerKey="" headerValue="Select Story Type" list="StoryTypeIdListPrepare" listValue="story_type_name" listKey="story_type_id" name="story_type_id" required="true" /] The naming conventions run the StoryTypeIdListPrepare statement for us. <select id="StoryTypeIdListPrepare" resultClass="Data"> SELECT id AS story_type_id, name AS story_type_name FROM story_type </select> So that we don't need any glue code in the StorySave action. Likewise for the StorySave action. The conventions can see that it's a "Save" action, so if nothing else is specified, then it can use the "BaseSave" action, and automatically choose between the StoryInsert and StoryUpdate statements to story input, and, likewise, the StorySelect statement to display a record for editing. In this instance, no concrete Struts Action or extra Struts configuration is needed. By asking for the StorySave_input action, we tell the framework what page and base service to use, leaving us to write only the pages and SQL statements. Just like model 1, except it's all testable, and we can override special cases as needed. Anyway, that's what all these commits are about :) -Ted. |
From: Ted H. <hu...@ap...> - 2006-10-17 11:35:26
|
Logs through r58 SP-3 Add convention of deriving from bean name the prefix, and therefore statement names, if not given. Add Chain interface and ChainService implementation. SP-1 Update to Struts 2.0.1 SP-3 Change from ! (bang) as separator to _ (underscore). SP-3 Remove obsolete files. SP-3 Implement PrepareAction using a ServiceChain. SP-3 Updata JavaDocs. SP-3 Invert the implementation (again) so that the service id can be specified as a parameter. We still need a stub action in the Spring configuration, to obtain the bean factory reference, but only one per base class. The action tag isn't working for me (see dev@ thread), so we still have a prepare clause in the Spring configuration to populate the StoryTypeIdList, but that should go away eventually. SP-3 Update tests. SP-3 Update comments. SP-3 Remove obsolete file. |
From: Ted H. <hu...@ap...> - 2006-10-04 12:14:35
|
SP-3 Add update service and combine with insert into Save. SP-3 Add convention of deriving from bean name the prefix, and therefore statement names, if not given. SP-6 Refactor for interfaces, including a wrapper interface around SQL Data Mapper, which simplifies calls by client methods. Next is a "chain" Service that lets us aggregate several finely-grained services into a macro service. The use case being a UI page that needs to fill several dropdown boxes and what. Each dropdown can have it's owns service, which we can chain together into a single composite service for an input action. (And then we dress it up with SiteMesh.) |
From: Ted H. <hu...@ap...> - 2006-10-02 09:34:12
|
SP-3 Add initial Selenium test suite for Submit Article (see http://www.openqa.org/selenium/). Note that these "client" tests are following the MSS and extensions from the use case. Next, I'll dress the page up a bit and add SiteMesh for the background chrome. |
From: Ted H. <hu...@ap...> - 2006-09-27 00:28:27
|
SP-3 Add service for StoryInsert so input is saved to the database. Right now, the pages and actions are named "StoryInsert". Later that will would change to StorySave, and there will be an Action class that intelligently determines whether to delete to StoryInsert or StoryUpdate. But, one step at a time :) Add validation for StoryInsert. For some reason, StoryInsert-validation.xml and or /StoryInsert!services-validation.xml isnt working,. so I added it against the base class for now. Need to see if other applications that use wildcards and validation are working against Struts 2.0.0. ---- SP-3 Refactor naming conventions. Strong conventions reduce configuration overhead. * actions without a bang (!) pass through to pages with the same name (Welcome.do presents Welcome.ftl). * actions with a bang separator, like StoryInsert!input, call a Support method, and then present a page by the same name (StoryInsert!input.ftl). * action references that end in a bang (!) are "virtual" Actions that invoke a service by that name (less the bang). Both the action and service are invoked via Spring. Most of the services are template classes that just call a SQL query by the same name. A call to the "StoryInsert!.do" action, calls the StoryInsert service, which runs the StoryInsert SQL statement. In this chain of events, only the SQL statement exists. The Action and Service are virtual template classes that pass thru to the query. The input (if any) is passed along in a data transfer object, and output (if any) is passed back in the same object. Input to services can be validated using the standard validation.xml files. The bang is seen by the framework as part of the actin name. Input to the StoryInsert service, by way of the ServiceInsert!.do action, can be validated by providing a ServiceAction-StoryInput!-validation..xml file. Any runtime Exceptions are automatically caught by the global exception handler and presented to the client in a friendly format. ---- |
From: Ted H. <hu...@ap...> - 2006-09-20 12:32:47
|
SP-3 Add service for StoryInsert so input is saved to the database.Valldation is next. Right now, the pages and actions are named "StoryInsert". Later that will would change to StorySave, and there will be an Action class that intelligently determines whether to delete to StoryInsert or StoryUpdate. But, one step at a time :) -Ted. |
From: Ted H. <hu...@ap...> - 2006-09-19 00:28:07
|
Today, I prototyped the workflow for submit action, refined the service layer, and updated the Javadocs. A service to insert an article is next. -Ted. |
From: Ted H. <hu...@ap...> - 2006-09-11 19:19:30
|
On 9/11/06, tm jee <tm...@ya...> wrote: > Sounds good. Shouldn't there be a "list top stories" use case? or is it > refering to part of the "view latest news" usecase. Yes, the working code is falling under the "view latest news" use case. The commit list were working, it would be clearer, since the commit logs refer to the use case. r30: "SP-5 Add stub for Top Story List use case, along with services infrastructure." * http://opensource.atlassian.com/confluence/oss/display/sportsforge/Use+Cases In truth, I added top story as a "spike" to get the data-access infrastructure setup. * http://www.extremeprogramming.org/rules/spike.html -Ted. |
From: Ted H. <hu...@ap...> - 2006-09-11 19:13:11
|
On 9/11/06, tm jee <tm...@ya...> wrote: > Sounds fine to me. I think Jeff should be the more significant figure to > share thoughts on this. :-) He did, but the silly SourceForge mailler sets the reply-to wrong, and so people tend to reply to individuals rather than the list :( On 9/10/06, Jeff Wellings <je...@se...> wrote: > Sounds good to me. Thanks. > > Jeff > -Ted. |
From: tm j. <tm...@ya...> - 2006-09-11 15:10:01
|
<!-- DIV {margin:0px;}Sounds good. Shouldn't there be a "list top stories" use case? or is it refering to part of the "view latest news" usecase. I guess, in general, Ted's email is to say that we start off with implementing a use case available and as we go along, missing parts that warrant to be implemented should be backed by a use case. Did I got it right? ----- Original Message ---- From: Ted Husted <hu...@ap...> To: str...@li... Sent: Sunday, 10 September, 2006 2:21:43 PM Subject: Re: [Struts-sportsforge-dev] Use Case It's always hard to get any set of requirements "right" including the use cases. I wouldn't say that we need to reduce everything to use cases first. I would say that we should develop from a use case, since a good use case defines what we need to develop. (Like psuedo code.) Even after the code is implemented, I would like to look toward the use cases as part of the system documentation. So if we come back in six months and change something, we might want to change the use case too. If there is a use case embedded in the current application, * http://sectionxsports.com/ which someone finds interesting, I'd suggest that we could just write it up and start on the development. A big leg up on the application is that the original version is generally just fine. The purpose of the rewrite is to provide a firm foundation for future growth, and to allow the applicationt to be configured for other "sections". Personally, I look upon the "plausible" requirements and use cases the way extreme developers look upon units tests -- as a mechanism for team communication. -Ted. - Show quoted text - On 9/6/06, tm jee <tm...@ya...> wrote: > > > Hi guys, > > If not mistaken the plan we have is to get the use cases right so that we > could start working on the apps. I'd like to help out with the use cases, > but I am not sure about the actual use case. Is it ok if I guess what the > use case is and maybe, the users could correct it later on or is it better > to just leave it to the users (domain expert). > > Tia. > > rgds > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Struts-sportsforge-dev mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/struts-sportsforge-dev > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Struts-sportsforge-dev mailing list Str...@li... https://lists.sourceforge.net/lists/listinfo/struts-sportsforge-dev |
From: Ted H. <hu...@ap...> - 2006-09-10 21:25:18
|
I was thinking of posting an article to my blog about SportsForge. Does ths sound all right? ----- Once upon a time, Jeff Wellings, an earnest entrepreneur with technical savvy, setup a website to post stories and statistics about local high school athletes. Since he lives in New York State's Section 10, the website became <A HREF="http://www.SectionXSports.com/">SectionXSports.com</A>. It's up and running, and doing quite well, thank you. Well ... but not quite well enough. Like many Model 1 JSP applications, SectionXSports grew in the telling, and the application has become difficult to extend. It works, but making it work better has become a challenge. A challenge that open source might be able to answer. Jeff has placed the original SectionXSports code under the Apache License, and we setup a Struts "SportsForge" project to work on migrating the application to Struts 2. My ambition is to grow SportsForge into the archetypical Struts example. Not just a showcase, but a real application that people use everyday. Towards that end, we've setup a portal site with requirements, use cases, and issue tickets. The whole nine yards. <A HREF="http://opensource.atlassian.com/confluence/oss/display/sportsforge/Home">Feel free to drop by and see what we're up to</A>, and even lend a hand if you like. Who knows, before long, you might want to setup your own friendly neighborhood SportsForge to track the goings on for your own kid's team! ---- |
From: Ted H. <hu...@ap...> - 2006-09-10 21:01:57
|
Thanks, Toby. That seems to work great! I had to do > mvn jetty6:jetty6 first, since I didn' t have the plugin installed. But, now > mvn jetty6:run launches Jetty and I can go to > http://locahost:8080/sportsforge2 to open the application. Do you happen to know of a way to run Jetty in debug mode from IDEA? -Ted. On 9/6/06, tm jee <tm...@ya...> wrote: > > > Hey guys, > > Just to inform that I've made some changes to sportforge quite some time > ago, forgotten to send in an email to the mailing list. Only realise this > when i got email failure notice of svn commits. > > I've basically added jetty6 plugin to the pom.xml so we could start > sportforge with :- > > mvn jetty6:run > > added a spring-web dependency. > > that's about all. > > rgds > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Struts-sportsforge-dev mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/struts-sportsforge-dev |
From: Ted H. <hu...@ap...> - 2006-09-10 20:21:48
|
It's always hard to get any set of requirements "right" including the use cases. I wouldn't say that we need to reduce everything to use cases first. I would say that we should develop from a use case, since a good use case defines what we need to develop. (Like psuedo code.) Even after the code is implemented, I would like to look toward the use cases as part of the system documentation. So if we come back in six months and change something, we might want to change the use case too. If there is a use case embedded in the current application, * http://sectionxsports.com/ which someone finds interesting, I'd suggest that we could just write it up and start on the development. A big leg up on the application is that the original version is generally just fine. The purpose of the rewrite is to provide a firm foundation for future growth, and to allow the applicationt to be configured for other "sections". Personally, I look upon the "plausible" requirements and use cases the way extreme developers look upon units tests -- as a mechanism for team communication. -Ted. - Show quoted text - On 9/6/06, tm jee <tm...@ya...> wrote: > > > Hi guys, > > If not mistaken the plan we have is to get the use cases right so that we > could start working on the apps. I'd like to help out with the use cases, > but I am not sure about the actual use case. Is it ok if I guess what the > use case is and maybe, the users could correct it later on or is it better > to just leave it to the users (domain expert). > > Tia. > > rgds > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Struts-sportsforge-dev mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/struts-sportsforge-dev > > > |
From: Ted H. <hu...@ap...> - 2006-09-07 16:02:28
|
Today, I implemeted a stub for the "TopStory" use case, just to get the rest of the components in place. Next, I'll roll back to "Submit Article". ---- In a data-drven application, we spend a lot of time running queries and displaying the result. Often there is a 1:1 correlation between a query and a result page. If we run the "TopStory" query, a reasonable guess is that we will want to display the TopStory page. In iBATIS, we can give queries names like "TopStory". <select id="TopStory" resultClass="Data"> SELECT id AS story_id, game_id, author_id, sport_id, headline, body FROM story </select> And the iBATIS API provides several methods that let us run the queries by specifying the name and an object with any parameters the query needs. List queryForList( name, parameters ); Object queryForObject( name, parameters ); and so on. To run one of these methods, we need three things, a reference to a mapper, the statement name, and, optionally, the parameters. If we put at least the mapper and name together, we could call it a "Service" object. It's a Service because we could hand it input, and it could then run the query for us. If we create a Service object for every query, or even use case, an application can become unwieldy. So, people often create an object (or "facade") with a number of methods that each represent a Service. Fundamentally, the difference between most of these "services" will be which query is executed, which can be indicated by a ID. If we could inject the ID into a base object, we could create a number of different objects with the same base behavior, but a different outcome. A good way to inject data into a base object is to use Spring. If we create a base service object for obtaining a list, we could instatiate it via Spring and inject the statement name ("TopStory"). <bean id="TopStory" parent="ServiceList" singleton="true" /> If we wanted to run the service from an Action, we can give the Action access to the Spring factory. public String execute() throws Exception { BeanFactory factory = getBeanFactory(); String id = getService_id(); Service service = (Service) factory.getBean(id); Data data = getData(); service.execute(data); // do the deed return SUCCESS; } When we run the service, it calls the iBATIS API to run the query. public void execute(ServiceData data) throws Exception { List rows = getMapper().queryForList(getQuery_id(), data); data.set(getBeanName(), rows); } Since we set the outcome of the service back to our Data object, which is a property on the Action, we can display it from the page. <table> <@s.iterator value="data.TopStory"> <tr> <th>Headline</th> <td>${headline}</td> </tr> <tr> <th>Body</th> <td>${body}</td> </tr> </@s.iterator> </table> If we are doing this often, we can reduce the Action pattern to a wildcard mapping. <action name="*" class="actions.{1}"> <param name="service_id">{1}</param> <result>/{1}.ftl</result> </action> Now, if we name the pages, the services, and the statements alike, we don't have to add any more action mappings. We will need pages and statements, since those are unique. But the action mappings can pass through. This work flow is based on a framework that we've been using with ASP.NET for over a year now. As part of this project, I'd like to port it to Java and offer it back to iBATIS. What we have so far is in Subversion, if you'd like to have a look see. -Ted. On 8/30/06, Ted Husted <hu...@ap...> wrote: > Today, I fleshed-out the "Submit Article" use case. Next, I'll > implement the rest of the use case, so that we can click through it. > > * http://opensource.atlassian.com/confluence/oss/display/sportsforge/Submit+Article > > -T. |
From: tm j. <tm...@ya...> - 2006-09-07 01:52:50
|
Hey guys, Just to inform that I've made some changes to sportforge quite some time ago, forgotten to send in an email to the mailing list. Only realise this when i got email failure notice of svn commits. I've basically added jetty6 plugin to the pom.xml so we could start sportforge with :- mvn jetty6:run added a spring-web dependency. that's about all. rgds |
From: tm j. <tm...@ya...> - 2006-09-07 01:50:57
|
Hi guys, If not mistaken the plan we have is to get the use cases right so that we could start working on the apps. I'd like to help out with the use cases, but I am not sure about the actual use case. Is it ok if I guess what the use case is and maybe, the users could correct it later on or is it better to just leave it to the users (domain expert). Tia. rgds |
From: Ted H. <hu...@ap...> - 2006-08-30 12:16:58
|
Today, I fleshed-out the "Submit Article" use case. Next, I'll implement the rest of the use case, so that we can click through it. * http://opensource.atlassian.com/confluence/oss/display/sportsforge/Submit+Article -T. |
From: Ted H. <hu...@ap...> - 2006-08-29 12:23:40
|
I went to lookup something in the original version, and realized we had setup a "v1" folder under struts/SportsForge in anticipation of a "v2" folder. Accordingly, I moved the SportsForge2 folder to struts/SportsForge/v2. If you checkout SportsForge, you'll pickup the change, and the old SportsForge2 folder can be removed from your working copy. If you are using the IDEA project, it should work just fine in the new location. (Toby, have you worked with the IDEA project generation target that we have in Struts 2?) -Ted. |
From: Ted H. <hu...@ap...> - 2006-08-28 14:36:57
|
Today, I did a little more work on the "Submit News Story" use case. * http://opensource.atlassian.com/confluence/oss/display/sportsforge/Submit+News+Story I setup a use case template and moved the narrative over. Next, I'll flesh-out the steps and implement the workflow. Note that the narratives should try to describe the simplest possible case, and the description should include hard details. Ideally, we can use the narrative to mockup the input forms and prompts, and turn the detail into input for the initial unit test. To simplify the Submit News Story case, I made Angelo a registered user, submitting a story with no photos, in the other category. I cribbed the story text from the SectionX site, though a non-game story would be better :) -Ted. |
From: Ted H. <hu...@ap...> - 2006-08-28 14:13:25
|
Thanks, Toby. I've been trying to get the commit email notifications to work with the SF SVN site, but so far no joy. :( -T. On 8/28/06, tm jee <tm...@ya...> wrote: > Hi guys, > > Added pom.xml to SportForge2. > > rgds |
From: tm j. <tm...@ya...> - 2006-08-28 07:31:25
|
Hi guys, Added pom.xml to SportForge2. rgds |