> OK, I've been lurking on this list for some time, so > nobody here knows me, > but I do want to weigh in on this issue on Jason's > side. I'm relatively new > to WebWork, using it for a new Web application > project started in March. I > was responsible for evaluating the various frameworks > available, then > setting up the core design practices and training the > rest of the team. > > We have made extensive use of the CRUD Action pattern > - easily the bulk of > the code for the app administration and configuration > components. It made a > great deal of sense to me and the other developers - > a common set of data > with a small number of closely-related operations on > that data. Pretty much > the definition of an object. Seemed cleaner than > extending that same class > two or three or four times just to override > execute(). > > I realize this capability could be dangerous in the > wrong hands. ;-) Our > standard is to only use this pattern when all the > actions use the same > domain object(s) and back the same basic view. I > think this still satisfies > the Single Responsibility Principle, because there is > little or no risk of > breaking other app components if you have to update a > method in this Action > class. More likely is that a feature change or bug > fix will impact the > entire Action anyway. > > We have thus far avoided the whole wild-card > capability completely, both in > action definitions and in validation. Stars and > bangs and brackets - oh my! > Had the feel of getting dangerously clever, at least > for a newbie group just > learning its way around the framework. I can't speak > to which parts of that > work and really make life easier (yet). Besides, it > wasn't documented in > Jason & Patrick's book. :-) (Where, BTW, the CRUD > action approach is > described in the chapter 'Best Practices,' so it's > always been clear where > they stand on that. Maybe I've been brainwashed...) > > We have run into a couple of validation cases where > an > ActionClass-Method-validation.xml would get us into a > bit of trouble, for > example when calling 'save()' on a new User vs. an > existing User. In this > case, we defined two actions ('saveUser' and > 'saveNewUser') that mapped to > the same method and used the > ActionClass-actionName-validation.xml. True, it > wouldn't have been much harder to define two methods, > one of which simply > delegated to the other. Seems like a basic Java vs. > XML trade-off. > > Still, I favor using the action name because the idea > is that the validation > framework is externalized. If you have to make code > changes - new no-op > methods or even new no-op class extensions - just to > provide hooks for your > validation framework, then it really isn't very > externalized, is it? > Defining a new action in XML is in many ways the > equivalent of a code > change, but as Jason pointed out the action > represents the logical app > operation and may include different interceptors and > other decorations in > addition to validation. Mapping multiple actions to > the same method is a > convenience in the case where new decorations are > sufficient to handle all > needed functional changes. The whole point of > decorations is to change the > behavior of a class without having to modify the > class itself, right? > > Not sure my opinion is yet worth a full $.02, but > there it is. :-) BTW, > thank you all for your hard work. I was REALLY > impressed that you committed > to merging Struts and WebWork back together. > Resolving honest differences of > opinion and healing schisms is much harder than > writing code. It is > appreciated. > > Jay > -------- > Jay H. Hartley, Ph.D. > Senior Software Engineer/Architect > Modius, Inc. >
Thanks for writing up what I was trying to say better than I was ;-) Jason p.s. Glad the book helped. --------------------------------------------------------------------- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=78156#78156 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]