Some comments inline.
On Mon, 14 Feb 2005 07:15:27 -0800 (PST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Don Brown said:
>
> > 1. The chain logic should be separate from the application logic, which
> > could, however, use common-chain. I'm fine with using a chain command
> > to replace Action, as long as it can be made clear the line between the
> > two processes. One defines how all requests should be processed, and
> > the other, how this individual request should be handled.
>
> Fair point. I presume the Action execution, as it stands now, is one link of
> the overall "request processing" chain... I might go so far as to make it so
> that defining an Action is actually defining a chain, and I mean that it
> ALWAYS is that, even if the majority use case is a chain with a single
> command. Subchains I believe are not a problem from my reading, and that's
> all this would be.
Since one can do this already (via ChainCommand), that doesn't strike
me as a strong argument to change the nature of Action.
>
> > a. A single class which combines the request logic and request
> > "model", or as we call it, ActionForm. Best implemented in WebWork2,
> > the action class has setters for the form data, but also an execute()
> > method containing the request's logic code. This pattern is great for
> > simplicity and keeping the action code servlet api independent, since
> > the framework handles calling setters so the class can deal with regular
> > Java types. The disadvantage of this pattern is, for a moderately
> > complex application, you have a ton of classes.
>
> While I am usually a big fan of cutting down class count, this is one
> instance I wouldn't be happy doing so. I actually think the separation of
> Actions and ActionForms in Struts now is excellent, although I've never been
> thrilled with the name ActionForm, but that's not a major point :) This is
> actually one of the mistakes we made with the framework I was involved
> with... if we had thought of such a separation, I believe the end result
> would have been superior.
One case this particular approach doesn't seem to cover as elegantly
is multiple buttons (in JSF parlance, "commands") that do different
things on the same data (save versus cancel button, page navigation
links, ...). If that would require multiple classes fo the same form,
I don't think that would be superior.
>
> Even if there are examples of where the combined approach works well, I think
> keeping them decomposed allows for more flexibility, which is never a bad
> thing :)
>
> > b. Multiple action methods per class ala DispatchAction. This pattern
> > is better in the current Struts world where the form is separate from
> > the action, so the action is rather small. DispatchAction (and its
> > children) allow you to group related actions into one logical unit,
> > cutting down the class count. In this pattern, the ActionContext and
> > ActionForm are passed into each execute-type method, letting the action
> > pull out what it needs. This disadvantage to this approach is your
> > action code is very tied to its environment (ActionContext in this
> > case), and you still need to define your forms somewhere else.
>
> All of our controllers (Actions in Struts parlance) were essentially
> DispatchActions, although we took a different tact with it... when you
> defined your "mappings", you specified the class, as you do in Struts, but we
> also defined the method to be called for a given mapping. What this allowed
> us to do is make all our controllers POJOs, and didn't require any parameters
> to make it work. Everything was declarative. This has pluses and minuses,
> but I think the pluses outweigh the minuses.
>
> I wonder if Struts should consider such a thing? Make it so Actions don't
> have to implement any interface or extend any class, and add the method to
> the mapping. That has the effect of "giving the inheritance tree back to the
> application developer", i.e., no more forced inheritance squashing the one
> chance at inheritance an Action has.
>
> > To me, having a single class with an execute(ActionContext) takes the
> > disadvages of both approaches without the benefits of each; the worst of
> > both worlds if you will. I believe the best solution is similar to JSF
> > where the action class is combined with the form, and yet the action
> > class can be any POJO that can contain any number of request processing
> > methods. Ideally, this action/form class would be able to span multiple
> > pages to define a logical process, possibly using Java continuations.
>
> Interesting... I actually see that as being the BEST of both worlds :) I of
> course leave open the possibility that I completely missed something, but
> failing that it's a matter of perspective I suppose :)
FWIW, this is sort of the approach Shale takes, but with a twist:
* You normally have a 1:1 mapping between views and a backing bean,
but there are ways to share (for example, a "search" widget on every
page of your app should be able to share the same backing logic).
* You bind either the components, or the values, of input fields to
corresponding public properties in the backing bean. The latter
is more like how Struts form beans (and WebWork2 actions) do it.
The former is more useful if you need to manipulate component
properties directly to effect the view. And, you can combine these
approaches as necessary.
* Each command (button or hyperlink) on the view can be bound to
an individual execution method, so you don't need any dispatch type
chains to disambiguate (sort of like DispatchAction).
* Here's the twist -- the calling sequence of the method you bind to
is very simple:
public String submit_action(); // Method name is arbitrary
The ShaleContext (analogous to ActionContext) is available as a
request scope attribute if you need it; it implements [chain]'s Context
interface so you can choose how tightly you want to bind your logic
to Shale APIs. (With the test framework that is also available with
Shale, this is less an issue than it is for Struts.)
(Maybe expose ActionContext as a thread local so you don't have
to pass it explicty?)
* The backing bean *can* implement the ViewController interface
if you want the convenience of lifecycle callbacks, but you are
not required to do so. (The reason you want to is the convenience
of prerender() callbacks, which are useful for the same reason that
Controller is useful in Tiles -- you use it to pull the data you need
to render this view from the model, and it's only called if this is the
view that is going to be rendered.)
* Recently, I was able to get the same view controller functionality
working on JSF subviews (i.e. something included dynamically via
RD.include(), the way that Tiles does things). You might want to
think about whether actions should belong to an entire page, or to
an individual Tile, when an app actually uses Tiles.
Shale doesn't have direct continuations support, but I'm also
experimenting with other approaches that make multiple-page
interactions easier to deal with. That's still an area where some new
stuff is likely to get added.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
