> 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]
