Gabriel Sidler wrote: > So, we should really provide a set of methods similar to what we > offer for handling errors? > > public boolean hasMessages(); > public int messageSize(); > public int messageSize(String property); > public HashMap messages(); > public HashMap messages(String property); > public String messageMarkup(String header, String footer); > public String messageMarkup(String property, String header, String footer); > > (We need to rething the naming once we know what tools there will be.)
Yes. It's actually a superset of ActionErrors. All errors are messages, but not all messages are errors. So the message methods have to check under it's own key, and the message key, and report on the joinder of the two. My original code didn't actually do that :o( > Regarding the transaction tag, my understanding is that it is something > that should really be dealt with in the Action and therefore we don't > need methods to handle this in the template. Is that right? The token needs to be passed back by the form or a hyperlink, so that it can be compared with the token in the session. So the API does need to be able to check the request for a token, and output it if found. This applies to forms and (optionally) hyperlinks. One thing I forgot is the magic value for the CANCEL button, that the Actions uses to enage the isCancelled method. So we need a method that returns that too. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
