I tagged a version of MailReader Zero that was using a single namespace and (some) multiple methods at
* http://sq1-struts2.googlecode.com/svn/tags/mailreader-zero-flat/ I've started to refactor the "head" to use multiple namespaces and single-method classes, but so far I'm only half done. * http://sq1-struts2.googlecode.com/svn/trunk/articles/mailreader-zero/ -Ted. On 10/2/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > Finally got a chance to look this over. Here's a few things: > > 1. You don't need action annotations unless you are actually doing work. > You can safely hit URLs without actions and only results. I noticed that > you had a empty Hello action and a number of actions inside classes that > didn't do anything (i.e. login-input inside Login). My favored pattern > is to keep it simple like this: > > ===== code ===== > package actions; > @Result(name="success", location="bar", type="redirect-action") > public class Foo extends ActionSupport { > } > > ===== JSP ===== > WEB-INF/results/foo-input.jsp > > Links into the foo form reference foo-input and the form submits to foo. > You can also do the GET/POST check that Rails suggests and collapse > everything to just foo. In most cases I just use inline redirect actions > for cancel buttons and redirect after post and this reduces the clutter > even more. > > 2. I tend to shy away from multiple actions inside classes. For crud I > use s:action for form preparation (this is actually better because it > reduces overhead of preparing the form on success). For other types of > forms, if I have to share logic (rarely) I use a base class, but > otherwise I just make one class per URL. In most re-use cases I > introduce re-usable services in a separate tier to clean out actions and > make the one action per URL simpler to code. > > 3. Likewise, I try to avoid heavy re-use of result pages and try to > stick with the convention based approach. It seems to make the code more > readable and easy to get into. For CRUD I setup something like this: > > ==== Classes ==== > List.java - Fetches the existing entities for display > Prepare.java - Used only via the s:action and implements Action > Edit.java - Fetches an existing entity and renders the edit form > Save.java - Inserts a new entity > Update.java - Updates the existing entity > Delete.java - Deletes an entity or entities > > ==== Results ==== > add.jsp - Includes form.jsp and passes a parameter to set the action > type (i.e. save) > edit.jsp - Includes form.jsp and passes a parameter to set the action > type (i.e. update) > form.jsp - The CRUD form used for insert and update > list.jsp - Lists the current entities > > I'm planning on putting up a CRUD demo for SmartURLs at some point, when > I get time. This will help illustrate what I'm talking about a bit more. > > -bp > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
