On 1/23/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> If you were using a dispatch action, aren't there decent odds that
> you'd need to dispatch cancellations too?
If Struts did not consider itself a god and if it were not doing
things automatically "because this is how we do things in Struts", I
would simply had event handlers like:
public ActionForward store(...) {
populate(myForm);
validate(myForm);
doStoreStuff();
}
public ActionForward cancel(...) {
doCancelStuff();
}
This way I would not care about population, cancellation or
validation. This is just an event, one of many, cancel or whatever. I
want Struts to do heavy lifting, but I hate when it lift things
without my command.
> You think? Can anyone even describe use cases where it's valuable to
> have some cancel process happen? I mean realistic use cases, not
> just exercises.
Load stuff for edit, then cancel. May need to unlock data if using
pessimistic locking. Say, booking a ticket. Or buying a thing when a
store has limited number of them. Instead of returning tickets/things
into a pool when session ends, these things can be returned when user
cancels his selection.
> Anyway, my main goal in choosing a solution is one that is lowest
> impact to users and to the code architecture, unless we have more
> positive use cases for improving the "cancel" feature -- so if you
> think more people would actually use it, let's understand how/why,
> and from there we can figure out what the right route is (and what
> facets of the solution are for which version of Struts.)
There are suggestions on how to improve
DispatchAction/LookupDispatchAction. We just need to finally do it,
including explicit handling of cancel event and better definition of
events themselves. It is not important whether stripping image suffix
was first invented by DJ or not, he submitted this idea to Struts
using public mailing list, and according to Apache 2.0 licence this is
a contribution and can be used. We will be able to kill several
rabbits with one shot (er... that was Russian proverb). By improving
DispatchAction the users of regular action classes will (1) stay
unharmed, (2) be encouraged to switch to dispatching action, (3) will
get a nice and simple event dispatching with arbitrary and localizable
buttons, (4) Struts will be able to claim that it *has* event system
;-) (Frank, any particular reason for not liking dispatching actions?)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
