Don Brown wrote: > 2. Explicitly handle form population.
I've never been quite sure whether it should be the RequestProcessor's job to populate an ActionForm, or whether a ActionForm should populate itself. The reset() method is essentially a pre-population extension point, and validate is essentially a post-population extension point, but there is no populate extension point ~:)
> 1. Pass parameters to a form in the configuration
You might want to extend form-bean and put your parameter there. You'd then look up the form-bean through the ActionMapping to retrieve it.
One suggestion might be to add a standard "parameter" properties to form-bean and action-forward, for the same reasons we have the parameter property on action-mapping. You could then just say
<form-bean name="UserForm" type="com.oroad.stxx.xform.DOMForm" parameter="/WEB-INF/models/user.xml"/>
And if there were a ActionForm populate method (instead of a processPopulate method), you can have your DOMForm grab the parameter from the ActionMapping, and do whatever it needs to do to itself.
Likewise, the form-bean might give us a place to retrofit a populate method (assuming we decided that we wanted one). There could be a processPopulate property on the form-bean, and if set to false, the RequestProcessor could call form.populate(mapping,request) instead of performing its own behavior.
-Ted.
Don Brown wrote:
This reminds me, I think Struts should be more flexible supporting the configuration of other types of forms or extensions to existing forms (like the aforementioned modification to the dynaform). While you can specify any form class, you cannot pass properties to that instance making it difficult to develop generic, powerful forms, like dynaforms, outside the Struts framework.
For example, I've been working with an extension of ActionForm that uses XML as its model, allowing the XML to be modified directly through Struts saving heaps of mapping code. In addition to naming my class, I'd like to specify the XML file it should use as a model. Currently, I do this although it is admittedly a hack:
<form-bean name="UserForm" type="com.oroad.stxx.xform.DOMForm"> <form-property name="xml" type="/WEB-INF/models/user.xml" </form-bean>
In addition, in order to have control over the form population, I have to extend RequestProcessor and override processPopulate().
Therefore, I think there should be a way to:
1. Pass parameters to a form in the configuration 2. Explicitly handle form population.
Perhaps there are strong reasons why this wouldn't be a good idea, but I'd like to hear them. I apologize if this topic has already been dealt with.
Don
On Fri, 15 Aug 2003, Ted Husted wrote:
In terms of simplifying the maintenance of DynaActionForms, I was wondering if we had tried anything like this yet?
<form-bean name="inputBean" type="org.apache.struts.validator.DynaValidatorForm" proxy="com.mycompany.project.businessBean" />
where the proxy class would be introspected, and String or boolean dynaproperties generated for each public property? (Rather than specify them ourselves as XML.)
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]