> > > Tool 4) Action Messages > > > ----------------------- > > > > > > Class: org.apache.velocity.tools.struts.MessagesTool > > > > > > Recommended name in context: msgs [snip] > Actually the classes are not the same. It's > org.apache.velocity.tools.struts.MessageTool and > org.apache.velocity.tools.struts.MessagesTool
oops. :-) see! i'm confused already! > But I completely agree that it's confusing. I just didn't have a > a good solution and was hoping that someone has. :-) yeah i was hoping the same. i'll try and think about it myself too... > 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. yeah, i think you're right. most of my complaint was with the naming similarities... although the relationship and functional similarity to ActionErrors/ErrorsTool does make me wonder if there isn't some way to connect/combine those with ActionMessages. but, again, it's still fuzzy to me. so i guess i'd have to say that if 'MessagesTool' does stay on its own, then i'd prefer naming the class ActionMessagesTool and finding some sufficiently different suggestions for context keys. $msg and $msgs will not do. hmm. maybe it's MessageTool's key that needs changed... what about $i18n instead of $msg? it's not as pretty, but it's a fairly accurate description. > > > Tool 5) Action Form > > > ------------------- > > > > > > Class: org.apache.velocity.tools.struts.FormTool [snip] > 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. multiple forms, eh? hmm. how would that work with getForm() or getBean()? anyway, yeah, i agree the get(String s) trick would be misleading. (but still nifty... :-)) > 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() +1 yeah, that's clear and accurate. > 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. heh. that's true... still, i agree we should have this. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
