> 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).
In the case of Hello, the purpose of the class is to access the message resources, which are tied to the "actions" package. Of course, we could change from package.properties to something else, but the underlying problem is that without a "Hello" class "hello.jsp" isn't considered part of the "actions" package. The Login input method that just called super.input wasn't needed (might have been development cruft). But, @ActionName for login-input is needed to access message resources (same issue as Hello). > 2. I tend to shy away from multiple actions inside classes. In MailReader, both approaches are tried. For Register, there are RegisterInput and RegisterUpdate classes. For Subscribe, there's one class with multiple methods. I'm hard pressed to come up with a technical justification that supports using one approach over the other. Here, the decision was driven by whether the validations were easy to share between methods. (For Register, they are not.) It seems to be a matter of perspective. One perspective holds that the Action is a facade for the Model, and Action methods should be operations on the Model. From the Action/Model perspective it follows that the usual crud operation should be part of a single class rather than spread over multiple classes. Another perspective holds that the Action is a unit of work, or transaction script. From the Action/Transaction perspective, it follows that each crud operation should be a separate class, because each operation is a separate unit of work. Given a perfect API, I tend to favor the "Action/Transaction" school, but there are still holes in our validation API which makes sometimes makes one approach easier than the other. Even under the transactional approach, we still need to deal with common notions like "input" and "cancel", and we shouldn't assume that the ActionSupport versions will always suffice. In the context of heuristic "convention over configuration", if matching "login-input" one strategy would be to * Look for a LoginInput class * Look for a Login class with an input method Matching methods the same way we match results (only in reverse) would eliminate most of the @ActionName annotations in MailReader Zero. We could eleminate the rest by providing a way to associate a message resources package to actions that fall back to the default ActionSupport class. (Would it make sense for XWork to be able to associate a message resource with a namespace?) > 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. Feel free to rework the MailReader, including the DAO layer. We even have use cases :) * http://StrutsUniversity.org/MailReader+Use+Cases and a JPA-compatible set classes available * http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-mailreader-jpa/ -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
