On Thu, 2 Aug 2001, Ted Husted wrote:
> I very much like the idea of DispatchAction; I'm just trying to minimize
> the use of query strings.
>
Of course, it works with a hidden variable too.
> To do that, I've been using the ActionMapping Parameter property for
> other things. So if a mapping performs a select, I might have
> parameter="select" in the config. The Action then uses that to determine
> what to do, since my Actions tend to be multipurpose, and used by
> several different mappings.
>
> In the case of the CRUD operations, the ancestor method looks at this
> parameter, and calls a method in a Helper object. The actual calls to
> the Data Access object happen here. All the top level instance does is
> call crud() with almost the same signature as perform() itself uses. The
> signature uses interfaces, and you could actually have one of these crud
> Actions per application, just by changing Helper objects.
>
> I working on new version of this, with Helpers that use ArrayLists
> instead of RowSets. I need to have milestone version done tomorrow, and
> should have some classes to share next week.
>
Should be interesting to see what you come up with.
> On the DEV side of of this, I'm wondering if we should to start to treat
> "parameter" like a real query string, and get multiple use out of it.
> DispatchAction, could just look for the first "parameter", but we could
> have others in the usual way, like parameter="method&task=select". This
> could mean replicating the getParameter* methods from
> HttpServletRequest, but have them act on the internal parameter property
> instead.
>
> If parameter were multi-use, it might also be useful to have
> DispatchAction look for a cannonical "perform" parameter first, as in
> parameter="DISPATCH_ACTION=select" (before reverting to the original
> hehavior). That way I would have the option of giving each "perform()"
> it's own ActionMapping.
>
The "parameter" attribute of an <action> element *is* multi-use, at least
to my way of thinking -). It is interpreted solely by the Action class
you have specified, so it can mean whatever that Action wants it to mean.
DispatchAction happens to use the particular interpretation of parameter
being the name of a request parameter to be processed. But FooAction,
BarAction, and BazAction can certainly have their own interpretations.
To handle lots of parameters to an Action, one very simple mechanism
would be to interpret the single "parameter" included in an <action> as
the name of a properties file resource containing your other configuration
items. Otherwise, you have to go to the pain of extending ActionMapping
to have some additional properties, and then using nested
<set-property) elements to configure them.
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
>
Craig
>
> "Craig R. McClanahan" wrote:
> >
> > On Mon, 23 Jul 2001, Ted Husted wrote:
> >
> > > I would, yes.
> > >
> > > I use one Action class for all four CRUD operations on a table (or
> > > logical view), along with any special retrievals.
> > >
> >
> > Are you mapping this to four different actions? if so, you've got four
> > instances of the Action class (even though it's all the same class, so
> > your source code maintanence load is lower).
> >
> > One way to eliminate this small amount of overhead would be to try the
> > dispatch standard action (org.apache.struts.actions.DispatchAction). This
> > lets you (in effect) give a single Action class more than one
> > "perform" method, selected by a request parameter. This can be very
> > helpful in situations where different Actions logically fit together, like
> > CRUD maintenance transactions.
> >
> > Craig McClanahan
>
