Now i know that the deprecation of ActionErrors != deprecation of

works just fine, no formatting in props file. thats enough, i'll leave these folk to get back to their work. and i'll continue lurking on the list rather than talking. cheers mark On 13 Jan 2004, at 18:45, Richard Hightower wrote: > 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 . > > 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:mark.lowe@talk21.com] > 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. > > > > Sorry I'm sure there are lots of great reasons, but > > 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 : >> >> >> >> <%=message%> >> >> >> >> 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: >> >> >> >> >> : >> >> >> >>
>> >> 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: >> >> >> >> >> >> : >> >> >> >> >> >> >> <%=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:mark.lowe@talk21.com] >> 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. >> >> > 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:matthias@wessendorf.net >>> URL: http://www.wessendorf.net >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org >>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org >> For additional commands, e-mail: struts-dev-help@jakarta.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org >> For additional commands, e-mail: struts-dev-help@jakarta.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: struts-dev-help@jakarta.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: struts-dev-help@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-dev-help@jakarta.apache.org