It's is hard to argue with sound reasoning like canine's genitalia and queen of abomination.
What don't you like about this? You never stated a reason. :) The html:errors tag forces you to put HMTL markup in the resource bundle. EVIL! (sorry I could not think of a something catchy like canine's genitalia) Resource bundles are for I18N not HTML markup. I don't see a problem with <html:errors property="foo" />. I am trying to understand. What is the beef? Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc-mind.com/consulting.htm#StrutsMentoring -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 11:21 AM To: Struts Developers List Subject: Re: Deprecated: ActionError Sure I know how to get the messages out using html:messages but i cant see how this improves on html:errors I've tried using jstl to drill to the specific error but just cant do it. <c:out value="${messages.errors.foo}" /> Sorry I'm sure there are lots of great reasons, but <html:errors property="foo" /> was the canine's genitalia IMO and the messages lib to access errors is the queen of abominations in respect to html:errors .. On 13 Jan 2004, at 17:51, Richard Hightower wrote: > > The action:messages tag works out pretty well. > The advantage is that you don't put markup in your resource bundle. > Markup belongs in the JSP not the resource bundle. > > Context-Sensitive Error Messages > > Here is an example usage: > > You may want put the error message right next to the field. You can do > that > with <html:messages>: > <html:text property='userName'/> > <html:messages id="message" property='userName'> > <font color="red"> > <%=message%> > </font> > </html:messages> > > The above iterates over all error messages for the property userName. > If you leave on the property="userName" attribute you get all of the > error > messages. > > If you have a form with a lot of properties and something goes wrong, > you > want to give the user more cues than just error messages at the top of > the > page. For example, you may want to turn the label red by field. You > can do > this by using logic:messagesPresent: > > <logic:messagesPresent property="userName"> > <font size="4" color="red"> > </logic:messagesPresent> > <bean:message key="inputForm.userName"/>: > <logic:messagesPresent property="userName"> > </font> > </logic:messagesPresent> > <html:text property='userName'/> <br /> > > By specifying the property attribute as userName, we are checking to > see > whether there are any error messages for the userName property. If > there > are, we turn the font of the userName red. The following would turn the > label red and put the error text by the field: > > > <logic:messagesPresent property="userName"> > <font size="4" color="red"> > </logic:messagesPresent> > <bean:message key="inputForm.userName"/>: > <logic:messagesPresent property="userName"> > </font> > </logic:messagesPresent> > <html:text property='userName'/> > <html:messages id="message" property='userName'> > <font color="red"> > <%=message%> > </font> > </html:message> > > Let me know if this helps. All of the above is covered in Professional > Struts by James Goodwill and I. > > Rick Hightower > Developer > > Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm > > Struts/J2EE consulting -- > http://www.arc-mind.com/consulting.htm#StrutsMentoring > > > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 13, 2004 8:36 AM > To: Struts Developers List > Subject: Re: Deprecated: ActionError > > > Sorry I don't usually post this group but is there actually a sensible > replacement for action errors yet? > > That messages stuff still falls short of offering the same level of > slickness that action errors does, perhaps this is due to he > html:errors tag but i personally and i imagine others all that > messagesPresent nasty mess. > > There's still no clear means of accessing a single property of the > messages vector/array/list (whichever it is). I've asked this question > a few times on the user list, but what exactly is the replacement for > action errors and the accompanying tags. > > <logic:messagesPresenet bla bla is disgusting and there's no obvious > way to drill to the property in the common situation of wanting to > display an error by a form element. > > Sorry wont post again, but its a tad irritating that something this > useful is being deprecated in favor of some rancid camel's jism of an > alternative. > > Cheers Mark > > On 13 Jan 2004, at 14:15, Matthias Wessendorf wrote: > >> Hi, >> >> i watched at the sources and figured out, that >> ActionError is deprecated so that i have to use ActionMessage. Okay. >> >> The add() in ActionErrors is also deprecated, because of first. fine. >> >> So i watched the Validator-Sources (class FieldChecks) >> i saw there ist ActionMessages in use for "errors". >> for the deliverd Methods. >> >> So i looked at our validate() in ActionForm, >> but there is still ActionErrors. >> >> So i wondered, why the validator uses Messages and >> the validate() uses Erros... >> >> and also i saw, that the validator gets >> initialized with an ActionErrors-object in: >> Resources.initValidator(); >> >> inside of initValidator() >> this happends: >> validator.setParameter(ACTION_ERRORS_PARAM, errors) >> >> but "key" for errors is this: >> private static String ACTION_ERRORS_PARAM = >> "org.apache.struts.action.ActionMessages"; >> >> >> the first parameter of "setParameter()" is called: >> "parameterClassName". >> so the errors gets initialized as an ActionMessages-object, isn´t? >> >> >> so question: >> why is the ActionErrors not deprecated? >> >> in release-notes i saw: >> "Although not removed, in many cases you should replace the deprecated >> ActionErrors with the preferred ActionMessages to ensure correct >> operation." >> >> >> why not in all? >> >> it would be fine, to know this ;-) >> >> greetings >> >> Matthias >> >> >> Matthias Weßendorf >> Email: mailto:[EMAIL PROTECTED] >> URL: http://www.wessendorf.net >> >> >> --------------------------------------------------------------------- >> 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] > --------------------------------------------------------------------- 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]
