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]>
