hey Gabe, good stuff. comments inline... > -------------------------------------------------------------------------- ----- > PROPOSAL > > Context Tools for Velocity for Struts, Phase 2 > ---------------------------------------------- > > > Tool 1) Handling of URLs > ------------------------
sounds good! +1 > > Tool 2) Message Resources > ------------------------- > > Class: org.apache.velocity.tools.struts.MessageTool > > Recommended name in context: msg i like this a lot! ...but i'm not sure how this works with/against/over/around/under/through the ActionMessages stuff in #4. see below. > Tool 3) Error Handling > ---------------------- > > Class: org.apache.velocity.tools.struts.ErrorsTool > > Recommended name in context: errors > > Methods: > > public boolean exists() > > public int getSize() > > public int getSize(String property) > > public HashMap getAll() > > public HashMap get(String property) +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. > 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? > 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... Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
