I've created Struts validation.xml generation from Struts ValidatorForm
subclasses using XDoclet. In fact, it is part of XDoclet 1.2 that is
releasing at any moment now. I'd highly recommend you at least use
Validator for your validation, and I'd suggest you check out the
generation that I added to see how it fits (or does not fit) in with
what you are doing.
I also use XDoclet to generate a starter JSP and
ApplicationResouces.properties pieces from a form bean. This particular
generation is custom to our environment, but its easy to do and is
working very nicely.
Erik
Ian Tomey wrote:
> Hi all, let me run this past you.
>
> Concerned way changes to data objects can sometimes be missed by forms/actions, I am
> currently working on an XDoclet extension for generating form type objects (by that
>I mean
> items that validate and can render their content and are designed to be embedded into
> forms) from data beans.. to give you an idea - at the moment its looking something
>like
> this for marking a field for generation on a bean:
>
> /**
> *@xform:form-field
> *@xform:display format="currency.2dp"
> *@xform:validate allowNull="false" min="0" max="50000"
> */
> public abstract double getValue();
>
> In the generated form-like class currently we get auto generated an intermediate
>String
> object for holding the formatted output in and out of the form, plus format and
>validate
> entries in the corresponding functions:
>
> protected String _value;
> public String get_value() { return _value; }
> public void set_value( String _value) { this._value= _value; }
>
> public ActionErrors validate(ActionMapping mapping, HttpServletRequest request,
> ActionErrors errors ) {
> ActionErrors errors = new ActionErrors();
>
> value = FormatTools.validate( request, errors, _value, "value", false, 0, 50000
> ).doubleValue();
>
> return errors;
> }
>
> public void populateTextFields( HttpServletRequest request ) {
> _value = FormatTools.format( request, value, "currency.2dp" );
> }
>
> Now this is quite nice, it saves us a whole bunch of time writing and maintaing a
>form
> object & formatting/validation, plus the bean developers can quite easily change the
>valid
> values from their projects. (this is using our internal formatting & validation
>tools, but
> the whole idea could be used to auto-generate validator xml). But it got me thinking
>that
> there might be a way to encapsulate some more information about the display of the
>object.
> for example:
>
> /**
> *@xform:form-field
> *@xform:display type="select" values="currencyList"
> */
> public abstract String getCurrency();
>
> where "currencyList" is some plugin object that can be called to get a list of
> currencies. In the JSP page, instead of writing out <html:select> and
> <html:optionsCollection> tags, because the item knows about how to display itself it
>can
> handle it's own rendering eg:
>
> <b>Currency</b> <xForm:render property="currency"/>
>
> This means that if say the bean developer suddenly wanted to change currency from
>being a
> string to an id of a currency, the only changes to be made would be in the data
>object
> definition + tags and the currencyList plugin.
>
> That seems like a good idea to me - anybody else got some other views or ideas?
>
> Regards
> Ian
>
>
>
>
> --
> 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]>
