I want to make sure I'm getting this. The "form definition" at the end of your message is the XML that your form bean uses? If so, is there any reason you haven't put some of the stuff that can go in an HTML form there (say "enctype"). How does the validator end up getting invoked after the HTML form has been submitted?
Then the designer is told the name of the form and uses the form bean from his/her Velocity template to create the whole HTML form, however is appropriate? The form bean API is the same for any form? Any chance of seeing the code for that form bean? Wondering how coupled it may be to the expectation that it's going to end up in a VelocityContext. I'm not sure I understand: "There are separated templates for each type of control supported that are (TADAA...) just Velocity templates." Where do those come into play? Thanks for the message, Donnie -----Original Message----- From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 10:35 AM To: Velocity Developers List Subject: RE: #macro functionality I think you should have a form bean for doing that. The approach I am following is having a form definition in XML which parameterizes a form bean. Some details: - Validation logic can be in Java or in script. Anyway, it is just an extra Validation object which is also parameterized in the XML definition; - Other cases where different-then-usual logic often pops up will follow the same approach - pluggable in the form object as above - and for really hard stuff, just make your own form object; - The form object exposes any properties necessary to build the HTML form via very simple Velocity template; - And takes care of all the "complicated" stuff as handling defaults, processing user input and validating elsewhere. There are separated templates for each type of control supported that are (TADAA...) just Velocity templates. You can even use them as skins. (No, I am not building an MP3 player!) These templates are processed by the form object behind the scenes just to avoid loads of #macros across de final template. Finally, the user (designer) chooses how much he wants to customize the final template. He can just do something like: <form ... > $myForm.full.form </form> to get the complete form or: $myForm.full.view for a detailed view of the data, but he can also go: <form <br> <b>$myForm.fields("name").caption<b> $myForm.fields("name").control <br> ... or even <br> <b>$myForm.fields("name").caption<b> <input type="text" name="name" title="$myForm.fields("name").hint" value="$myForm.fields("name").value" size="$myForm.fields("name").size" /> <br> ... And the template to define a text control is similar to the above. Something like: <input type="text" name="$field.name" title="$field.hint" value="$field.value" size="$field.size" /> And the template to define the simple form view that one gets from the above mentioned construct: $myForm.full.form would be something like: <table> #foreach($field in $form.fields) <tr><td><b>$field.caption</b></td><td>$field.control</td></tr> #end </table> And finally, the form definition is something like: <form name="myform"> <field name="name" type="text" control="text" size="50" caption="Name" hint="Enter your name" ... /> <field name="age" type="int" contro="text" caption="Age" hint="Enter your age" ... > <validator type="min-max" min="15" max="120" msg="You must be kidding!"/> </field> .... <validator lang="java" class="xpto.xyz.MyValidatorClass" /> </form> Use your imagination to fill the blanks, because that is exactly what I am doing... and will be doing for a while. So, in such a scheme you can do it really simple or you can go as detailed as you want. And I really see not need to change Velocity to make such thing work. This implementation is still far from complete but on the templating side is being MUCH easier than the previous one I did - with FreeMarker - because Velocity makes it so much easier to get stuff from the Java side. And the complex stuff, one does in the Java side. (Of course that I am not trying to use JSP! hehehe) Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de > -----Original Message----- > From: Donnie Hale [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 27, 2001 2:44 AM > To: Velocity Developers List > Subject: RE: #macro functionality > > > Jon, > > >>What convinced me that it was ok was that it didn't add any new > 'language' > to Velocity. It simply allows you to create reusable bits which > actually has > the potential to simplify things.<< > > And that's all I'm wanting to do. Struts <html:form> tag library has a lot > of simplifying (for the web developer, at least :) code in it. > And at least > one other person wanted a knock-off Velocity form macro library. > To achieve > that, calling args by name-value seems most appropriate. > > Donnie > > > -----Original Message----- > From: Jon Stevens [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 26, 2001 8:18 PM > To: velocity-dev > Subject: Re: #macro functionality > > > on 11/26/01 5:22 PM, "Donnie Hale" <[EMAIL PROTECTED]> wrote: > > > Now if we want to debate whether #macro should exist at > > all... ;) > > FYI, I was against it as well for a long time. > > What convinced me that it was ok was that it didn't add any new 'language' > to Velocity. It simply allows you to create reusable bits which > actually has > the potential to simplify things. > > Needless to say, you can always disable the ability to use #macro. > > -jon > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
