James, I'm glad you answered :-)) Personally I don't think that struts was successful because it missed functionality. I think it was (and is) successful although it missed functionality. I don't think it is a reason to abstain from this functionality, especially, if it's really needed. The fact, that you are happy with it, doesn't mean everyone is, we see it often enough on the struts-users list.
My personal reason to make my teams switch to struts since 2001 wasn't the Action/Mapping/Forward. This is something many teams had by the time in their own frameworks, and which isn't hard to implement. The cool thing were the taglibs. jsp:useBean wasn't sufficent, you had to write a lot of scriptlets, and iterations were a mess. Struts helped you to remove 90% of scriptlets. This was cool, this looked better, the pages were readable again. The other cool thing was, that it all came in one package. You could start with simple actions and bean/logic taglibs, move along to action forms, better maintain your pages and page structure with tiles, and so on. If you haven't used it, it didn't hurt you either, it was simply there. I don't see how arg0Name/arg0Property would hurt struts after there is an arg0 attribute already. I don't see how proper logging gonna hurt struts. But I'm only a user and therefore not seeing the global picture. I don't have exact data, but I'd guess, that 50% of struts users switched to EL (and struts-el) because they had no other chance. 30% are probably developing and maintaining own taglibs. That means, they check out struts-source of a release, let's say 1.1 or 1.2, develop their tags on-top or patch struts.jar and will probably never be able to upgrade (just have this situation in one of the projects I'm consulting). Now, why is it good for anyone? And yes, I've got the message, and won't write anything to this topic or attempt to volunteer again. Regards Leon > -----Ursprüngliche Nachricht----- > Von: James Mitchell [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 29. August 2005 22:26 > An: Struts Developers List > Betreff: Re: Some thoughts. > > > I'm glad you asked ;) > > arg0Name? > arg0Property? > > Why not also add arg0NameKey and arg0PropertyKey, so I can > put them in the bundle for better reuse? > > Oh wait! I'm not done. Since they are in a different > bundle, we also need to be able to specify a bundle key... > > arg0BundleKey > > So... > <bean:message key="msg.hello" > arg0Name="user" > arg0Property="userName" > arg0BundleKey="customer" > arg1Name="accts" > arg1Property="accounts.totalOfActiveAccounts" > arg1BundleKey="accounts" > arg2Name="accts" > arg2Property="accounts.totalBalance" > arg2BundleKey="accounts"/> > > ...that's almost perfect. Only problem is my boss just told > me to add 3 more things to the welcome message, so can we > make this tag take 10 arguments? > > <back-to-reality/> > > Where does this end? The term 'slippery slope' comes to mind here. > > There is a point where enough is enough. And that's why > Struts has been so successful. Guided by the likes of Craig > and friends, knowing when to say 'no' is what separates > Struts tags from some of the other whiz-bang-do-it-all tags > that have come and gone. > > I think the one enhancement I would have liked to see is the > ability to specify a map of strings that get appended as > attribute="value" to any tag (specifically, for me, the form > tag). Other than that I am perfectly happy using what we have. > > For the above example, you could just as easily put this > message together in your Action, and add it as a request > attribute, and simply write it out. No need for a scriptlet. > No changes needed to your form bean. Same effect, a lot less effort. > > Thanks. > > > -- > James Mitchell > Software Engineer / Open Source Evangelist Consulting / > Mentoring / Freelance EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > Yahoo: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: callto://jmitchtx > > > > > On Aug 29, 2005, at 1:37 PM, Leon Rosenberg wrote: > > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > >> Gesendet: Montag, 29. August 2005 18:15 > >> An: Struts Developers List > >> Betreff: Re: Some thoughts. > >> > >> James Mitchell wrote: > >> > >>> Well, the taglibs are more or less feature complete. So > >>> > >> any changes > >> > >>> are really "extensions" or "nice-to-have". > >>> > >> > >> I think this is the part of the equation I don't necessarily agree > >> with... I think saying they are feature-complete in terms of what > >> they were meant to be years ago *is* accurate. > >> They do what was set out to provide, > >> > > > > > > After some reasoning, I must say that I must disagree with James > > statement. > > A very simple example. I need to greet the user in his language. > > I will help a message like this in my messages_en.properties: > > msg.hello=Hello {0} > > And in messages_de.properties > > msg.hello=Hallo {0} > > > > Now I have my page, the right locale and the user object. > Without EL, > > how can I ever right the proper greeting? > > The only way today would be: > > <bean:define id="username" type="java.lang.String" name="user" > > property="userName" toScope="page"/> > > <bean:message key="msg.hello" arg0="<%=username%>"/> Imho > the taglib > > can't be considered complete, as long as there are < %= %> > in the jsp. > > It would be so simple to provider the message tag with argXName/ > > argXProperty similar to name/property attributes it already has and > > parallel to > > arg0-arg5 > > it already has. > > <bean:message key="msg.hello" arg0Name="user" > > arg0Property="userName"/> > > > > Would it hurt someone? I don't think so. > > And there are a lot of examples where really simple > functionality is > > missing in struts tags. > > For example compare tags don't allow second bean/property as value. > > > > > > Other thing. How many struts-tags actually do log? Maybe 20%? > > Shouldn't it > > be unified? > > > > If there are people, who are ready to implement this, why > wouldn't you > > let them? :-) > > > > Regards > > Leon > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
