Re: Flexible form support (was Re: Simplifying DynaActionForms)

[Craig R. McClanahan]

On Sat, 16 Aug 2003, Ted Husted wrote:

> Date: Sat, 16 Aug 2003 07:00:52 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Flexible form support (was Re: Simplifying DynaActionForms)
>
> Steve Raeburn wrote:
> > The problem with adding a 'parameter' is that you then find a need for
> > another parameter, etc etc. Is  not suitable here? Or, even
> > better, nested configuration elements under form-bean.
>
> Yes, set-property would work here, just like everywhere else. I'm just
> saying that if action has a general-purpose "parameter", then maybe
> form-bean and forward should have one too. People would not then have to
> extend action-forward or form-bean every time they wanted to try
> something out.
>
> IMHO, the "general purpose" parameter has been a useful feature of
> ActionConfig/ActionMapping and is worth applying elsewhere. We just have
> to be quick to remind people that if they outgrow the general purpose
> parameter, then they should start extending the base object and using
> set-property. (As people often do now.)
>

+1

> -Ted.
>
>

Craig

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

Re: Flexible form support (was Re: Simplifying DynaActionForms)

[Ted Husted]

Steve Raeburn wrote:
The problem with adding a 'parameter' is that you then find a need for
another parameter, etc etc. Is  not suitable here? Or, even
better, nested configuration elements under form-bean.
Yes, set-property would work here, just like everywhere else. I'm just 
saying that if action has a general-purpose "parameter", then maybe 
form-bean and forward should have one too. People would not then have to 
extend action-forward or form-bean every time they wanted to try 
something out.

IMHO, the "general purpose" parameter has been a useful feature of 
ActionConfig/ActionMapping and is worth applying elsewhere. We just have 
to be quick to remind people that if they outgrow the general purpose 
parameter, then they should start extending the base object and using 
set-property. (As people often do now.)

-Ted.



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

RE: Flexible form support (was Re: Simplifying DynaActionForms)

[Steve Raeburn]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 15, 2003 5:55 PM
> To: Struts Developers List
> Subject: Re: Flexible form support (was Re: Simplifying DynaActionForms)
>
...
> 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
>
>  name="UserForm"
>   type="com.oroad.stxx.xform.DOMForm"
>   parameter="/WEB-INF/models/user.xml"/>
...

The problem with adding a 'parameter' is that you then find a need for
another parameter, etc etc. Is  not suitable here? Or, even
better, nested configuration elements under form-bean.

Steve



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

Re: Flexible form support (was Re: Simplifying DynaActionForms)

[Ted Husted]

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

 
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:


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?

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  - ,
  Struts in Action - ,
  JSP Site Design  - .


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