Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/ActionErrorsAndActionMessages

The comment on the change is:
Updated SVN links

------------------------------------------------------------------------------
- With the many [http://jakarta.apache.org/struts/api/deprecated-list.html 
deprecations] related to the ActionErrors and ActionError classes, there are a 
variety of questions relating to:
+ With the many [http://jakarta.apache.org/struts/api/deprecated-list.html 
deprecations] related to the !ActionErrors and !ActionError classes, there are 
a variety of questions relating to:
   * the relationship between 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/ActionMessages.html
 ActionMessages] and 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/ActionErrors.html
 ActionErrors] and between 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/ActionMessage.html
 ActionMessage] and 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/ActionError.html 
ActionError]
   * the differences between 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/Action.html#saveErrors(javax.servlet.http.HttpServletRequest,%20org.apache.struts.action.ActionMessages)
 Action.saveErrors(...)] and 
[http://jakarta.apache.org/struts/api/org/apache/struts/action/Action.html#saveMessages(javax.servlet.http.HttpServletRequest,%20org.apache.struts.action.ActionMessages)
 Action.saveMessages(...)]
   * the differences between the 
[http://jakarta.apache.org/struts/userGuide/struts-html.html#errors 
html:errors] JSP tag and the 
[http://jakarta.apache.org/struts/userGuide/struts-html.html#messages 
html:messages] JSP tag.
  
- To summarize, the difference between the classes 
ActionErrors/ActionError/ActionMessages/ActionMessage has '''absolutely 
nothing''' to do with the difference in behavior in Action.saveErrors(...) and 
Action.saveMessages(...)  
+ To summarize, the difference between the classes 
!ActionErrors/ActionError/ActionMessages/ActionMessage has '''absolutely 
nothing''' to do with the difference in behavior in Action.saveErrors(...) and 
Action.saveMessages(...)  
  
- The difference between the classes is zero -- all behavior in ActionErrors 
was pushed up into ActionMessages and all behavior in ActionError was pushed up 
into ActionMessage.  This was done in the attempt to clearly signal that these 
classes can be used to pass any kind of messages from the controller to the 
view -- errors being only one kind of message.
+ The difference between the classes is zero -- all behavior in !ActionErrors 
was pushed up into !ActionMessages and all behavior in !ActionError was pushed 
up into !ActionMessage.  This was done in the attempt to clearly signal that 
these classes can be used to pass any kind of messages from the controller to 
the view -- errors being only one kind of message.
  
- The difference between saveErrors(...) and saveMessages(...) is simply the 
attribute name under which the ActionMessages object is stored, providing two 
convenient default locations for storing controller messages for use by the 
view.  If you look more closely at the html:errors and html:messages tags, you 
can actually use them to get an ActionMessages object from any arbitrary 
attribute name in any scope.
+ The difference between saveErrors(...) and saveMessages(...) is simply the 
attribute name under which the !ActionMessages object is stored, providing two 
convenient default locations for storing controller messages for use by the 
view.  If you look more closely at the html:errors and html:messages tags, you 
can actually use them to get an !ActionMessages object from any arbitrary 
attribute name in any scope.
  
  While we're clarifying, the difference between html:errors and html:messages 
is purely in syntax and model -- both tags *default* to look for an 
ActionMessages object under 
[http://jakarta.apache.org/struts/api/org/apache/struts/Globals.html#ERROR_KEY 
Globals.ERROR_KEY] despite the difference in names.  I wasn't part of the  
history, but I'm assuming that around the same time that people were realizing 
that there's more than one kind of message to pass, they also realized that 
sometimes you want more flexibility in displaying them.  html:messages provides 
more flexibility at the cost of more typing.  Niall Pemberton has posted more
  [http://www.niallp.pwp.blueyonder.co.uk/HelpTagsErrorsAndMessages.html 
details] on the differences between html:messages and html:errors on his 
website.
  
  I hope this helps to clarify things.  I would strongly encourage people to 
have a look inside the Struts source code, as it's really quite clear when you 
look under the hood.  You can see what happens in validation by examining the 
"processValidate" method in RequestProcessor:
- 
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java?view=markup
+ 
http://svn.apache.org/viewvc/struts/action/trunk/core/src/main/java/org/apache/struts/action/RequestProcessor.java?view=markup
  
  You can see what happens with saveErrors and saveMessages by examining those 
methods in Action
- 
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/action/Action.java?view=markup
+ 
http://svn.apache.org/viewvc/struts/action/trunk/core/src/main/java/org/apache/struts/action/Action.java?view=markup
  
  You can see what the tags do by looking at their respective source files:
- 
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/taglib/html/MessagesTag.java?view=markup
+ 
http://svn.apache.org/viewvc/struts/action/trunk/taglib/src/main/java/org/apache/struts/taglib/html/MessagesTag.java?view=markup
- 
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java?view=markup
+ 
http://svn.apache.org/viewvc/struts/action/trunk/taglib/src/main/java/org/apache/struts/taglib/html/ErrorsTag.java?view=markup
  

Reply via email to