> In many Struts projects I worked on we deliberately modified the > functionality to use methods off the same class, and it was one of the > reasons that I liked webwork so much. I think it is elegant that you > can use one action class for all/most of the CRUD calls, and the > interceptors allow for applying / disallowing validation based on the > standard method names being used.
Yup. I like this approach as well. Using the excludeMethods param of Validation and Workflow interceptor to restrict validation is pretty elegant too for me at least. > Additionally, I find it sometimes useful to add > sub-packages for actions that return responses from AJAX calls. I guess > this could be called syntactic sugar, but it is good to isolate the > URL's and sometimes I want to keep them together rather than have a > generic "all-ajax" package. Agree. :-) And subpackages could be used to group stuff ,say, that one might not want it to be decorated by sitemesh. rgds ----- Original Message ---- From: Ian Roughley <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Thursday, 3 August, 2006 11:45:45 PM Subject: Re: [s2] Validation Ted Husted wrote: > On 8/3/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >> This is actually a feature that I like in WW/SAF, granted som times is >> makes more sense to use it than others, but that is always going to be a >> design decision. Can you further explain why you have come to the >> conclusion that they are not good practice? > > The "advanced" (but indispensible) features of the framework are > designed to follow the class hierarchy. We've put in (a lot of) > special-case handling to accomodate multiple alaises, but the > architectural grain is that a logical action is mapped to a Java class > with a single entry point, and the validations, messaging, and type > converters are all designed to attach to the class. > > The first thing that happens when we start using multiple aliases is > that we want different validations, messages, or type converters for > this alias or that alias. For example, we have special-case handling > for several magic aliases to keep validation from firing on "input" > and "cancel", and so forth. > > The cannonical approach would be to have an Input class and a Cancel > class, so that they do not inherit validators from some other action. > With modern IDEs and modern JDKs, maintaining a class for each action > does not seem so great a burden. > > Maintaining a set of very similiar and largely redundant mappings is a > burden, but given wildcards and other features, we can "normalize" the > mappings so that we can program-by-difference within the > configuration, just as we do with Java classes. > > I'm not suggesting that try to make it impossible to use multiple > alaises. But I am suggesting that the Struts 2 group should recognize > that multiple aliases are not a recommended practice, in the same way > that chaining actions are not a recommended practice. In many Struts projects I worked on we deliberately modified the functionality to use methods off the same class, and it was one of the reasons that I liked webwork so much. I think it is elegant that you can use one action class for all/most of the CRUD calls, and the interceptors allow for applying / disallowing validation based on the standard method names being used. The reasons you list above would make sense for having some "best practices" for when to use each method, but I wouldn't go as far as saying that it is "not a recommended practice". > >> In webwork I make use of nested packages. > > Could you explain a bit more about why this is a good practice? Is it > synantic sugar, or is the practice providing utility that is not > feasible with unnested packages? In a large project there are usually several large divisions, these can then be split into many sub-divisions. Sometimes even further divisions can be made. This is much the same way I use class hierarchies - not too flat, not too deep. Additionally, I find it sometimes useful to add sub-packages for actions that return responses from AJAX calls. I guess this could be called syntactic sugar, but it is good to isolate the URL's and sometimes I want to keep them together rather than have a generic "all-ajax" package. Wildcards would definitely assist, but I think we should still account for nested packages. > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
