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]



Reply via email to