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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to