Nathan Bubna wrote:
>
> hey Gabe, good stuff. comments inline...
I'm glad we are getting closer to a good solution.
> > Tool 3) Error Handling
> > ----------------------
[...]
> +1 i like this much better than the way i did it. only one suggestion...
> call the existence method 'exist()' instead of 'exists()'. it's better
> grammar that way.
Good point. Will integrate into the next version.
> > Tool 4) Action Messages
> > -----------------------
> >
> > Class: org.apache.velocity.tools.struts.MessagesTool
> >
> > Recommended name in context: msgs
> >
> > Methods:
> >
> > public boolean exists();
> >
> > public int getSize();
> >
> > public int getSize(String property);
> >
> > public HashMap getAll();
> >
> > public HashMap get(String property);
>
> ok, now i'm confused. we can't have two classes named
> org.apache.velocity.tools.struts.MessagesTool and i don't like the idea of
> having both a $msg and $msgs in the context. that's just asking for
> trouble. of course, i'd like to propose some solution, but i'm still very
> hazy on this whole ActionMessages vs. ActionErrors deal, so i'm not much use
> here at the moment. is there some way we can combine this into the
> ErrorsTool or maybe the MessageTool in #2?
Actually the classes are not the same. It's
org.apache.velocity.tools.struts.MessageTool and
org.apache.velocity.tools.struts.MessagesTool
But I completely agree that it's confusing. I just didn't have a
a good solution and was hoping that someone has. :-)
In Struts the corresponding JSP tags are
<html:messages ... />
<bean:message ... />
ActionMessage is the super class of ActionError. It is supposed to
generalize the concept of error messages to all possible types of
messages an action might want to make available to the view, like
for example notfifications, warnings, confirmations, etc. I believe
ActionMessage is new in the upcoming 1.1 release.
MessageResource (#2) is entirely different dispite the closeness in
nameing. It's deals with internationalized strings from a bundle of
NVP files.
So, the challenge is to find a good naming to make the difference
between action messages and message resources clear.
I need to think more about this. Maybe Ted has a suggestion?
> > Tool 5) Action Form
> > -------------------
> >
> > Class: org.apache.velocity.tools.struts.FormTool
> >
> > Recommended name in context: form
> >
> > Methods:
> >
> > public ActionForm getForm() // was getActionForm()
> >
> > public String getCancelName() // was getCancelMagicName()
> >
> > public String getToken()
>
> +1 for the most part...
> i like grouping this stuff together. i'm just not thrilled by the syntax.
> $form.token and $form.cancelName is good, but $form.form is a little
> redundant. here's a crazy idea for you... what would you think about
> giving FormTool a get(String s) method that would then do a little
> velocity-style reflection on the ActionForm itself? then we could do
> $form.foo instead of $form.form.foo. i'm not sure i'm sold on the idea
> myself just yet, but it could be fun...
That's an interesting idea, but I think it would be confusing. $form would
look like the form bean itself, but it isn't. It is really a tool that
provides methods to one *or* multiple forms in a template.
I just realize that getForm() is the wrong name anyway. What we are asking
for the not really the form but rather the bean that contains the values
entered/to be entered into the form. There may be multiple forms per template.
So, getBean() would probably be a more accurate naming. How about this:
public ActionForm getBean()
In a template this would look like this:
<input typ="text" name="username" value="$form.bean.username">
For efficiency the recommended use should be:
#set ($mybean = $form.bean)
<input typ="text" name="username" value="$mybean.username">
...
Note that the form bean is available in the request or session
attributes already. getBean() isn't really necessary. It just a little
convenience. I kind of like it because if there is a method in the API
this makes it explicit how to get a hold of the form bean.
Gabe
>
> Nathan Bubna
> [EMAIL PROTECTED]
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
