Michael Jouravlev wrote the following on 7/22/2005 2:58 PM:
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?
For one "what wouldn't work" that I proposed (granted that site is old
as the hills and I don't do things all the same way as I did back then,
but tell me specifically what 'wouldn't' work since you brought it up?
Don't go around giving noobs the impression that something there won't
work as intended. And what is the "javascript hack" that you speak of?
And, since when is STANDARD setting an attribute with a value by
javascript a 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?
Man, not sure why your bashing all over me here. I'm not saying don't
improve things and I'm glad you are. You act like I don't want things to
change for the better. Maybe before you start accusing me of being a
stick-in-the-mud you could ask me for some more clarification of why I'm
not all excited about certain 'changes'?
You didn't ask but I'll bring it up anyway, even though I have work to
do. First off what you have proposed isn't 'new.'
I don't like the total reliance on an attribute (or button name)
because without fail UIs change to become more complex and end up having
to support more than one type of behavior.
My main problem is that your approach seems to make it difficult to:
"change what dispatch method is called based on user events that happen
on the client(web) side."
For example what if you have a button that has a gereric name like
"save," but based on various user conditions that "save" might need to
later go to saveSpecialWay(), saveSomeOtherWay() ? Your button is only
going to submit to one type of action method... now you need logic in
the action to look at some other parameter (which had to be set by
javascript anyway), in order to change the flow.
As another simple example, imagine two checkboxes with a button PROCESS
FORM
[ ] Process Form as FooBar
[ ] Process Form as Bubba
[ PROCESS FORM ]
Now imagine a scenario where action methods fooBar(..) and Bubba(..)
already exist, as they might even being used from some other forms.
Yet in the form above how do you change what dispatch actoin your form
goes to when the user presses your button? I think your attribute
approach will have trouble with this. (vs a simple set some dispatch
parameter to what you want with javascript.)
Your other option that I see would be to have to create a new 'process"
method and have condtional logic in there to deal with some request
parameter and change flow based on that.
Granted all of this stems from a problem with dealing with HTML in the
first place, vs using some rich client type of UI, but regardless these
are real issues that I have to deal with all the time.
For some simple apps with just your save, edit, delete buttons, that
attribute approach is fine - but again, withouth fail, someone will post
on the struts list about "How do I go to different types of action
methods when they click on my button."
Another point you bring up in your docs:
"According to HTML specification, at most one submit element is sent
from browser to the server when form is submitted. If form is submitted
without explicitly clicking a button, the result depends on a browser.
Either no buttons are submitted, or the first button defined on the form
is submitted. If no butons is submitted, unspecified method is called.
Override this method to handle default submits."
The above will burn people all the time using lookupDispatchAction and
I'm guessing the attribute button name approach as well, YET under the
crusty old man approach the above is never a problem since your standard
hidden name="dispatch" will always have a default value - and
DispatchAction keys off of that and not attribute names.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
