On 7/22/05, Rick Reumann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
