On 7/22/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Rick Reumann wrote the following on 7/22/2005 1:33 PM:
>
> > onclick="myForm.dispatch.value='someDispatchMethod'"
> >
> > You can use this kind of code with almost anything (with images just
> > also add myForm.submit()). Easy to use and no need to figuure out how
> > yet another flavor of SomeonesNewAndImprovedAction works.
>
> To further add, I'm not saying I don't like these other solutions, but I
> like consistency. To me it's very easy for a developer to see a
> "dispatch" hidden variable on a page and quickly see how it might
> possibly be being set.
When you create a dialog box for Windows app, do you define the name
of the window handler right in the the definition of a dialog? Nope.
You define a button ID, and then anyone can catch the window message
having this ID.
I don't see how the approach that I suggested for user events is
worse. It handles submit buttons, image buttons and regular links in
uniform fashion, and html has a clear definition that a button
generates an event:
<input type="submit" name="DIALOG-EVENT-ADD" value="Add button" />
<input type="image" name="DIALOG-EVENT-LOGIN" src="login.gif" value="Log In">
How hard is that? Also, why an end user has to see the real names of
your handler methods? A little indirection does not hurt in this case.
Just define a map in your action, and you are done:
protected Map getKeyMethodMap() {
Map map = new HashMap();
map.put("DIALOG-EVENT-ADD", "add");
map.put("DIALOG-EVENT-LOGIN", "login");
return map;
}
Also, this is not only about simple mapping of button to a method.
"DIALOG-EVENT" is an event prefix, so it can be used to reset a
component using GET request method. Yep, I am trying to sneak
SelectAction into Struts core to pave the way for dialogs and for
Struts components.
> When you start adding alternative ways to have your disaptch method
> called, it becomes more confusing to try and figure out what actually
> gets called. This was a big beef I had with LookUpDispatchAction... it
> was so annoying to figure what button did what.. it was complicated by
> the fact that it's a good idea to use the ApplicationResources for the
> names of your buttons. Yet, think how annoying it is to figure out what
> happens... you have to look at the button, the app resources file, then
> a map in the Action, and then finally you can figure out what method
> gets called.
With SelectAction is is easier and faster than with
LookupDispatchAction. Why then LookupDispatchAction is in the core,
and SelectAction is not? Well, if *you* can live without it, this is
great. But what about a newbie who just wants a better dispatching
action? He wants to get all needed service from a framework. What are
you suggesting him? Go search mailing list, find Rick's site, read
lessons, see why it does not work, apply a Javascript hack?
Rick, your site is great, I picked up some great ideas reading it. But
I don't think that Struts will gain many new users with this attitude.
Now there are new frameworks, and they are better. Are you saying that
current Struts users are old and crusty and have their own ways, so
why bother trying to revitalize an old framework?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
