You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dave Newton <ne...@pingsite.com> on 2005/07/22 18:32:00 UTC
[FRIDAY] Re: SelectAction - an improved DispatchAction
Niall Pemberton wrote:
>I presume you're referring to the fact that Michael Jouravlev's flavour of
>DispatchAction uses the ".x" and ".y" suffixes which HTML appends to image
>button parameters to determine the method to execute as being "code
>purloined from Michael McGrady"? (If not, then what?)
>
>
No offense to anybody, but hasn't everybody had to deal with this issue
in one way or another if they've used images as buttons?
>P.S. Are we still pretending that Dakota Jack and Michael McGrady are not
>the same person?
>
>
I've been pretending that neither of them are people; much quicker.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
Clearly people don't even think it is worth understand what the hell
is going on here. They don't know much more about it than you did.
You should be careful about these things, in my opinion, and certainly
an open source project should be. I note that Niall was going to put
that code in and McGrady objected. Anyway, you are totally wrong that
your original "purloining" did not support image buttons. You are so
bereft of understanding what you are doing with what is supposed to be
your own code that you apparently cannot even see that. What a joke.
On 7/22/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/21/05, Dakota Jack <da...@gmail.com> wrote:
> > This code does not belong to Michael. It is purloined from
> > www.michaelmcgrady.com and other discussion on this list. Michael did
> > not even know the reasons for most of the code when he first proposed
> > it as his own. To think he could have coded it under those
> > circumstances would be akin to expecting a monkey to randomly type a
> > novel. So, I would be very hesitant, if I were a committer, to accept
> > his authority to offer this code.
>
> Jack, we already discussed this. You accused me in stealing your code
> before I added support for image buttons, and at that time I did not
> know about your code at all. Later discussion and your accusations
> made me realise that my code did not support image buttons. Therefore,
> I added support for image buttons after you mentioned the issue with
> them. I personally do not use image buttons so I was not aware of
> ".x"/".y" issues. The code itself does not seem to look like code on
> your website (do you want me to scan and check every page on your
> site? The link you provided does not point to specific code).
>
> If you look at the copyright notice on top of the class, you will see
> "Copyright 2001-2005 The Apache Software Foundation." I will be glad
> to put the same notice on all code located at
> http://struts.sourceforge.net/strutsdialogs, if committers decide to
> include this library into core Struts. I also do not claim that I
> wrote every line in SelectAction class. It is partly borrowed from
> DispatchAction and LookupDispatchAction.
>
> On 7/22/05, DGraham@evergreeninvestments.com
> <DG...@evergreeninvestments.com> wrote:
> > 2. History is riddled with examples of 2 or more people inventing/creating
> > the same (fundamentally the same) thing simultaneously.
>
> Dennis, with all due respect, I would not classify stripping a suffix
> from request parameter as invention. This is just a routine solution
> of a simple issue. Granted, I did not know about the issue before Jack
> started accusing me in stealing his code. Now I do know, so I added
> support for image buttons, based on the discussion.
>
> On 7/22/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> > I presume you're referring to the fact that Michael Jouravlev's flavour of
> > DispatchAction uses the ".x" and ".y" suffixes which HTML appends to image
> > button parameters to determine the method to execute as being "code
> > purloined from Michael McGrady"? (If not, then what?)
> >
> > I agree that, to my knowledge, Michael McGrady was the first person to
> > propose this technique on the Struts mailing lists/wiki, but to claim that
> > it is not possible for anyone else to come up with the same idea and that
> > they must have "purloined" it from his web site is ridiculous - its not
> > exactly rocket science. In fact the forerunner of Michael McGrady's idea was
> > the Struts ImageButtonBean which used similar techniques for the same
> > purpose. Michael Jouravlev has already stated on this list that he didn't
> > steal this idea from anyone else and since he wasn't around on the Struts
> > lists when the ideas were being discussed (about a year ago) I don't see any
> > reason not to believe him.
>
> Um, I stated that I did not steal any of Michael McGrady's ideas or
> code the first time Jack accused me in stealing. The first version of
> SelectAction did not deal with image buttons at all. Then, after
> series of accusations and after discussion about image button issues,
> I added support for it, based on the discussion. Again, I did that
> *after* initial accusations, but I do not claim intellectual ownership
> on solution for image buttons. I want to thank Jack for pointing out
> to the problems with image buttons.
>
> On 7/22/05, DGraham@evergreeninvestments.com
> <DG...@evergreeninvestments.com> wrote:
> > Let's recognize prior art: http://www.jguru.com/faq/view.jsp?EID=893423
>
> === cut here ===
> Author Ted Husted
> CreatedMay 27, 2002
>
> An endless source of aggravation is the HTML input image element. The
> specification says that browsers should treat this control like an
> image map. Unlike other buttons, it does not submit a string
> representing the button's label, it submits the X and Y coordinates.
> If you look at the HTTP post for an image button, you'll see it looks
> something like this
>
> myImageButton.x=200
> myImageButton.y=300
>
> For most other controls, a Struts developer can create a simple String
> property to represent the element. This clearly won't work with an
> image button, because it submits two "dotted" properties instead of a
> simple "name=value" entry like other elements.
> === cut here ===
>
> Just a note: the above is correct for MSIE; Firefox produces slightly
> different parameters:
>
> myImageButton.x=200
> myImageButton.y=300
> myImageButton=Log+In
>
> Which does not really matter, because it is still important to support MSIE.
>
> I also do not really like a solution with a separate action form, it
> looks too bulky for a simple dispatch. Thus, I just strip the suffix
> in the action.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/21/05, Dakota Jack <da...@gmail.com> wrote:
> This code does not belong to Michael. It is purloined from
> www.michaelmcgrady.com and other discussion on this list. Michael did
> not even know the reasons for most of the code when he first proposed
> it as his own. To think he could have coded it under those
> circumstances would be akin to expecting a monkey to randomly type a
> novel. So, I would be very hesitant, if I were a committer, to accept
> his authority to offer this code.
Jack, we already discussed this. You accused me in stealing your code
before I added support for image buttons, and at that time I did not
know about your code at all. Later discussion and your accusations
made me realise that my code did not support image buttons. Therefore,
I added support for image buttons after you mentioned the issue with
them. I personally do not use image buttons so I was not aware of
".x"/".y" issues. The code itself does not seem to look like code on
your website (do you want me to scan and check every page on your
site? The link you provided does not point to specific code).
If you look at the copyright notice on top of the class, you will see
"Copyright 2001-2005 The Apache Software Foundation." I will be glad
to put the same notice on all code located at
http://struts.sourceforge.net/strutsdialogs, if committers decide to
include this library into core Struts. I also do not claim that I
wrote every line in SelectAction class. It is partly borrowed from
DispatchAction and LookupDispatchAction.
On 7/22/05, DGraham@evergreeninvestments.com
<DG...@evergreeninvestments.com> wrote:
> 2. History is riddled with examples of 2 or more people inventing/creating
> the same (fundamentally the same) thing simultaneously.
Dennis, with all due respect, I would not classify stripping a suffix
from request parameter as invention. This is just a routine solution
of a simple issue. Granted, I did not know about the issue before Jack
started accusing me in stealing his code. Now I do know, so I added
support for image buttons, based on the discussion.
On 7/22/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> I presume you're referring to the fact that Michael Jouravlev's flavour of
> DispatchAction uses the ".x" and ".y" suffixes which HTML appends to image
> button parameters to determine the method to execute as being "code
> purloined from Michael McGrady"? (If not, then what?)
>
> I agree that, to my knowledge, Michael McGrady was the first person to
> propose this technique on the Struts mailing lists/wiki, but to claim that
> it is not possible for anyone else to come up with the same idea and that
> they must have "purloined" it from his web site is ridiculous - its not
> exactly rocket science. In fact the forerunner of Michael McGrady's idea was
> the Struts ImageButtonBean which used similar techniques for the same
> purpose. Michael Jouravlev has already stated on this list that he didn't
> steal this idea from anyone else and since he wasn't around on the Struts
> lists when the ideas were being discussed (about a year ago) I don't see any
> reason not to believe him.
Um, I stated that I did not steal any of Michael McGrady's ideas or
code the first time Jack accused me in stealing. The first version of
SelectAction did not deal with image buttons at all. Then, after
series of accusations and after discussion about image button issues,
I added support for it, based on the discussion. Again, I did that
*after* initial accusations, but I do not claim intellectual ownership
on solution for image buttons. I want to thank Jack for pointing out
to the problems with image buttons.
On 7/22/05, DGraham@evergreeninvestments.com
<DG...@evergreeninvestments.com> wrote:
> Let's recognize prior art: http://www.jguru.com/faq/view.jsp?EID=893423
=== cut here ===
Author Ted Husted
CreatedMay 27, 2002
An endless source of aggravation is the HTML input image element. The
specification says that browsers should treat this control like an
image map. Unlike other buttons, it does not submit a string
representing the button's label, it submits the X and Y coordinates.
If you look at the HTTP post for an image button, you'll see it looks
something like this
myImageButton.x=200
myImageButton.y=300
For most other controls, a Struts developer can create a simple String
property to represent the element. This clearly won't work with an
image button, because it submits two "dotted" properties instead of a
simple "name=value" entry like other elements.
=== cut here ===
Just a note: the above is correct for MSIE; Firefox produces slightly
different parameters:
myImageButton.x=200
myImageButton.y=300
myImageButton=Log+In
Which does not really matter, because it is still important to support MSIE.
I also do not really like a solution with a separate action form, it
looks too bulky for a simple dispatch. Thus, I just strip the suffix
in the action.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/25/05, Dakota Jack <da...@gmail.com> wrote:
> Why don't you do your own code and then submit that?
I did, but I acknowledge that using suffix with method name directly
in the parameter is easier than using prefix and a method map. But I
can return back to prefix, no big deal for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
McGrady already did this, Rick. You can just go get that too, MJ
> > Anyway, I am not suggesting to replace standard
> > DispatchAction with something else. I suggest just to add another
> > action, that is it. I use this action as base for my dialog stuff,
> > this is why I considered to offer it first, and then to offer
> > something else, class by class ;)
>
> I would just tweak the code to also allow check for the dispatch param
> if that is defined in the struts-config for that mapping. Then it could
> go through steps of "first" looking for that dispatch attribute and
> using it's var or if it doesn't find it then check for the attribute and
> then finally look for unspecified. This will lot the developer have the
> option to use the standard dispatch for when scenarios come up (such as
> the javascript checkbox case I described) comes up.
> >
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
Why are you submitting other people's code and then being a smart ass
about it? If it were my option, I wouild say "not in a million
years". I don't think you ever have that authority anyway. But, ask
McGrady, who already said, if you check the lists, that he doesn't
want the code in Struts, probably for the reasons he stated, which are
very different from yours.. If you continue on this tack, I would
strongly recommend you learn how the code actually works before
claiming it is yours. I get a huge kick, however, out of the fact
that no one else is calling you out on this, even though the facts are
as clear as they ever will be that you are not the author of spit.
Why don't you do your own code and then submit that?
On 7/25/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/23/05, Rick Reumann <st...@reumann.net> wrote:
> > > Anyway, sorry for being overly excited, I might have said something
> > > wrong. I just wanted Struts to continue to evolve. Seems that I chose
> > > a bad class to submit.
> >
> > I don't think it's a bad class to submit - I'm just not sure how
> > different it is than the other lookup action McGrady submitted?
>
> I agree, McGrady's approach using suffix instead of prefix is easier,
> works for regular or image buttons. I used his code and submitted it
> to Bugzilla. Jack, is it OK with you that I submitted your code?
>
> Maybe I should just patch DispatchAction class, keeping the name and
> simply adding functionality?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/23/05, Rick Reumann <st...@reumann.net> wrote:
> > Anyway, sorry for being overly excited, I might have said something
> > wrong. I just wanted Struts to continue to evolve. Seems that I chose
> > a bad class to submit.
>
> I don't think it's a bad class to submit - I'm just not sure how
> different it is than the other lookup action McGrady submitted?
I agree, McGrady's approach using suffix instead of prefix is easier,
works for regular or image buttons. I used his code and submitted it
to Bugzilla. Jack, is it OK with you that I submitted your code?
Maybe I should just patch DispatchAction class, keeping the name and
simply adding functionality?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 7/23/2005 5:34 AM:
> Rick, I am sorry and I want to publicly apologize. Sometimes I get too
> excited about something and I can go over the top. I am sorry, I did
> not want to bash you or hurt you in any way.
No problem:) It was Friday and I was edgy myself since the stupid code I
was working on work was giving me fits so I sounded testy.
> I would not like to have one button to call different methods anyway.
> I never program like that.
Sometimes this will come up, and it doesn't mean it's bad design. It
cuts down on development time and duplication of code when you can
sometimes reuse an html form. I've run into this numerous times.
Typically the form isn't used in 'drastically' different ways but it is
possible that the form will need to sometimes 'go somewhere else' when
it submits based on some client interaction with the client interface.
Normally this is easy to solve in your case since all you would need to
do is make sure to set up the attribute name before you get to the page,
then a button can submit to different dispatch actions..
name="${DIALOG-VAR}"
> I personally do not feel like having method names right in the HTML,
> but maybe I am wrong.
Well I got in this discussion with the other Michael before... I don't
see that much difference in whether you see the method name in the
dispatch param or in the attribute name? The basically equate to the
same thing.
> Anyway, I am not suggesting to replace standard
> DispatchAction with something else. I suggest just to add another
> action, that is it. I use this action as base for my dialog stuff,
> this is why I considered to offer it first, and then to offer
> something else, class by class ;)
I would just tweak the code to also allow check for the dispatch param
if that is defined in the struts-config for that mapping. Then it could
go through steps of "first" looking for that dispatch attribute and
using it's var or if it doesn't find it then check for the attribute and
then finally look for unspecified. This will lot the developer have the
option to use the standard dispatch for when scenarios come up (such as
the javascript checkbox case I described) comes up.
>
>
> It is 2am now... Yes, I guess this could be a problem. I will think of
> it. But why using "unspecified" should burn people? Unspecified means
> default, what is so difficult about that?
What I meant is that I don't think unspecified is always called when
there are mulitple submit buttons in an html page. I just remember
running into some annoying quirkiness with IE when I was back using
LookupDispatchAction and the user pressed "enter"
>
> Anyway, sorry for being overly excited, I might have said something
> wrong. I just wanted Struts to continue to evolve. Seems that I chose
> a bad class to submit.
I don't think it's a bad class to submit - I'm just not sure how
different it is than the other lookup action McGrady submitted? I know
yours does some really easy to use.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/22/05, Rick Reumann <st...@reumann.net> wrote:
> 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?
I did not mean that something from your site would not work. I guess
this whole paragraph was wrong and I want to take it back. Just strike
it out. I meant, what if he wants to have a different button caption
and does not want to use LookupDispatchAction, then he has to use
javascript to set handler name...
> > 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.
Rick, I am sorry and I want to publicly apologize. Sometimes I get too
excited about something and I can go over the top. I am sorry, I did
not want to bash you or hurt you in any way.
> First off what you have proposed isn't 'new.'
It is not new, but I put it together, I wrote some javadocs and I want
it just to get into the core, so that I and others could use it. What
is wrong with that? Is this class worse than LookupDispatchAction? I
do not think so.
> 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.
Um, I did not get this.
> 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.
I would not like to have one button to call different methods anyway.
I never program like that.
> 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.)
I personally do not feel like having method names right in the HTML,
but maybe I am wrong. Anyway, I am not suggesting to replace standard
DispatchAction with something else. I suggest just to add another
action, that is it. I use this action as base for my dialog stuff,
this is why I considered to offer it first, and then to offer
something else, class by class ;)
> 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.
It is 2am now... Yes, I guess this could be a problem. I will think of
it. But why using "unspecified" should burn people? Unspecified means
default, what is so difficult about that?
Anyway, sorry for being overly excited, I might have said something
wrong. I just wanted Struts to continue to evolve. Seems that I chose
a bad class to submit.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Rick Reumann <st...@reumann.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/22/05, Rick Reumann <st...@reumann.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, July 22, 2005 2:42 pm, Craig McClanahan said:
> The standard (HTML centric) set of JSF components was deliberately
> designed to use attribute names that are similar to (or identical to)
> the HTML attributes that they correspond to. The thinking was that
> newcomers to JSF who were using these tags would appreciate that
> familiarity.
Makes perfect sense.
> A component not in the standard set can, of course, use whatever
> attribute names it wants. The component set that comes with Creator 2
> EA, for example, uses "label" for the label of a Button :-).
Hey now, don't go giving me any reason to actually WANT to use Creator ;)
> Same basic issue, but even more so ... the Struts tags can *only* emit
> HTML, so it made the most sense to use attribute names that
> corresponded to what was actually getting emitted:
>
> IN: <html:button ... value="Save" .../>
>
> OUT: <input type="submit" value="Save" ...>
Fair enough, I can't say I wouldn't have made the same decision myself.
Thanks for the insight into the thinking. :)
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/22/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Since this topic is already a Friday topic, I don't feel bad going OT :)
>
> On Fri, July 22, 2005 2:04 pm, Craig McClanahan said:
> > <h:commandButton id="save" value="#{messages['save.button.label']}"
> > action="#{mybean.save_action}" .../>
>
> I noticed this last night watching a demonstration of Exadel Studio...
> Craig, why is it that the attribute of a button that defines what a user
> sees is "value" and not "label"? I know it really *IS* the value
> underneath, but wouldn't it be clearer if the attribute was "label"?
> Especially in the case of using the <button> tag, which presumably will
> become more prevalent, where there actually is a distinction between what
> is visible to the user and what the value is (I don't know what
> <h:commandButton> renders by the way).
The standard (HTML centric) set of JSF components was deliberately
designed to use attribute names that are similar to (or identical to)
the HTML attributes that they correspond to. The thinking was that
newcomers to JSF who were using these tags would appreciate that
familiarity.
A component not in the standard set can, of course, use whatever
attribute names it wants. The component set that comes with Creator 2
EA, for example, uses "label" for the label of a Button :-).
>
> I've noticed this with a lot of the Struts taglibs too... the attributes
> don't always describe what they really are. This complaint has been
> leveled against struts-config definitions too, but I'm not going there :)
>
> Just curious if there was some underlying logic to the attribute names I'm
> not seeing.
>
Same basic issue, but even more so ... the Struts tags can *only* emit
HTML, so it made the most sense to use attribute names that
corresponded to what was actually getting emitted:
IN: <html:button ... value="Save" .../>
OUT: <input type="submit" value="Save" ...>
> Frank
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Since this topic is already a Friday topic, I don't feel bad going OT :)
On Fri, July 22, 2005 2:04 pm, Craig McClanahan said:
> <h:commandButton id="save" value="#{messages['save.button.label']}"
> action="#{mybean.save_action}" .../>
I noticed this last night watching a demonstration of Exadel Studio...
Craig, why is it that the attribute of a button that defines what a user
sees is "value" and not "label"? I know it really *IS* the value
underneath, but wouldn't it be clearer if the attribute was "label"?
Especially in the case of using the <button> tag, which presumably will
become more prevalent, where there actually is a distinction between what
is visible to the user and what the value is (I don't know what
<h:commandButton> renders by the way).
I've noticed this with a lot of the Struts taglibs too... the attributes
don't always describe what they really are. This complaint has been
leveled against struts-config definitions too, but I'm not going there :)
Just curious if there was some underlying logic to the attribute names I'm
not seeing.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dave Newton <ne...@pingsite.com>.
Craig McClanahan wrote:
>This philosophy is one of the lessons we took to heart in designing
>JSF. In the particular case of buttons and hyperlinks, the label of
>the button and the binding to an action are separated and explicit:
>
> <h:commandButton id="save" value="#{messages['save.button.label']}"
> action="#{mybean.save_action}" .../>
>
>
Thank goodness there's another reader macro for JSPs!!! ;) (Or whatever
people call them in JSP, the #{, ${, etc.)
>PS: Don't tell DJ, but JSF has transparently supported image buttons
>and the ".x/.y" thing from the very beginning :-)
>
>
Only because you stole his code, ya' thievin' bastiges.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
Which has been a long time, then. I think this burgeoning technology
almost predates Java itself, doesn't it? Anyway, I don't believe
this. Let's see the proof, Craig. If you mean the image button
stuff, like the other rocket scientists, then that is irrelevant.
> PS: Don't tell DJ, but JSF has transparently supported image buttons
> and the ".x/.y" thing from the very beginning :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/22/05, Rick Reumann <st...@reumann.net> wrote:
> 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. I'm not saying these other solutions work this way (I know
> they don't), but I'm just making the point that I find it nice to have
> one consistent way of doing things that's easy for other developers to
> follow.
This philosophy is one of the lessons we took to heart in designing
JSF. In the particular case of buttons and hyperlinks, the label of
the button and the binding to an action are separated and explicit:
<h:commandButton id="save" value="#{messages['save.button.label']}"
action="#{mybean.save_action}" .../>
so you can grab button labels out of a resource bundle (or specify
them literally if you don't care about l10n), and specify a call to
the save_action() method specifically on each link so that you can
immediately see the linkage (or share action methods if you have more
than one button in your UI that should do the same thing).
>
> --
> Rick
>
Craig
PS: Don't tell DJ, but JSF has transparently supported image buttons
and the ".x/.y" thing from the very beginning :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
Yes. McGrady made a big deal of that. www.michaelmcgrady.com.
On 7/22/05, Rick Reumann <st...@reumann.net> 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 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. I'm not saying these other solutions work this way (I know
> they don't), but I'm just making the point that I find it nice to have
> one consistent way of doing things that's easy for other developers to
> follow.
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Rick Reumann <st...@reumann.net>.
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 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. I'm not saying these other solutions work this way (I know
they don't), but I'm just making the point that I find it nice to have
one consistent way of doing things that's easy for other developers to
follow.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
J. you don't even understand "your" own code. How can you make a decision?
On 7/22/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/22/05, Rick Reumann <st...@reumann.net> wrote:
> > I only see these current solutions having merit if you are *required* to
> > not have any javascript. For me, this will never be a requirement and I
> > doubt it will ever be. Since I can use javascript it's so easy for me to
> > just add
> >
> > 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.
>
> If something can work without Javascript and is as simple as a
> solution with Javascript, which one would you choose? Designing forms
> in HTML editor is simpler too, just drop a button and set name/value,
> no Javascript to wire.
>
> This is a rather generic solution, proposed to be included into Struts
> core, not a Javascript hack. Of course, in the end we can write
> everything as a servlet, but I thought that the whole purpose of web
> frameworks was to provide standard solutions for common problems.
>
> We can crawl back to our dark corners and use our own flawors of
> actions and scripts, watching the world changing.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/22/05, Rick Reumann <st...@reumann.net> wrote:
> I only see these current solutions having merit if you are *required* to
> not have any javascript. For me, this will never be a requirement and I
> doubt it will ever be. Since I can use javascript it's so easy for me to
> just add
>
> 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.
If something can work without Javascript and is as simple as a
solution with Javascript, which one would you choose? Designing forms
in HTML editor is simpler too, just drop a button and set name/value,
no Javascript to wire.
This is a rather generic solution, proposed to be included into Struts
core, not a Javascript hack. Of course, in the end we can write
everything as a servlet, but I thought that the whole purpose of web
frameworks was to provide standard solutions for common problems.
We can crawl back to our dark corners and use our own flawors of
actions and scripts, watching the world changing.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Rick Reumann <st...@reumann.net>.
Dave Newton wrote the following on 7/22/2005 12:32 PM:
> No offense to anybody, but hasn't everybody had to deal with this issue
> in one way or another if they've used images as buttons?
I haven't had to deal with it. I haven't look at Michael Jouravlev's
stuff but do remember discussing all of this with Michael McGrady.
I only see these current solutions having merit if you are *required* to
not have any javascript. For me, this will never be a requirement and I
doubt it will ever be. Since I can use javascript it's so easy for me to
just add
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.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FRIDAY] Re: SelectAction - an improved DispatchAction
Posted by Dakota Jack <da...@gmail.com>.
No is the answer.
On 7/22/05, Dave Newton <ne...@pingsite.com> wrote:
> Niall Pemberton wrote:
>
> >I presume you're referring to the fact that Michael Jouravlev's flavour of
> >DispatchAction uses the ".x" and ".y" suffixes which HTML appends to image
> >button parameters to determine the method to execute as being "code
> >purloined from Michael McGrady"? (If not, then what?)
> >
> >
> No offense to anybody, but hasn't everybody had to deal with this issue
> in one way or another if they've used images as buttons?
>
> >P.S. Are we still pretending that Dakota Jack and Michael McGrady are not
> >the same person?
> >
> >
> I've been pretending that neither of them are people; much quicker.
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org