Re: form generation via XDoclet + auto property rendering?

[Erik Hatcher]

Christopher Lenz wrote:
 Erik Hatcher wrote:
 
 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.
 
 
 This sounds interesting... could you provide some more info on what the 
 generated ApplicationResources.properties looks like (ie what keys are 
 being added etc.), and what exactly you mean with starter JSP?

The way our team develops is by creating the form bean first.  It 
extends (indirectly) from ValidatorForm.  We then have an XDoclet 
process we run if we want to generate a JSP page and the necessary 
resource keys.  It uses XDoclet and walks all the form fields.  Suppose 
the form bean says this:

/**
  * @struts.form name=SomeForm
  */
public class SomeForm extends ValidatorForm {
   //...

   /**
* @struts.validator type=required
*/
   public void setSomeField (String someField) {
 // ...
   }
}

It would generate SomeForm.jsp with stuff like this:

   tr
  thbean:message key=SomeForm.someField//th
  tdhtml:text property=someField//td
   /tr

And then a small properties file like this:

SomeForm.someField=Some Field

There is some tricks to make the description more readable by putting 
whitespace where words break with capitalization changes.  We simply 
copy SomeForm.jsp to whatever our real JSP filename should be into the 
right place and then paste in the generated keys into the production 
ApplicationResources.properties.  That is passive generation - we only 
do it once and then tweak the JSP from there on out and do not 
regenerate the same form again unless we desire to wipe out whatever 
changes we've made to the JSP.

Using the @struts.form tag and @struts.validator tags we also generate 
the form bean definitions in struts-config.xml and validation.xml for 
Validator.

Erik


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: form generation via XDoclet + auto property rendering?

[Erik Hatcher]

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=5 
 */ 
 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, 5
 ).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:
 
 bCurrency/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]