[ http://issues.apache.org/struts/browse/STR-311?page=all ]
David Evans reopened STR-311:
-----------------------------
Assign To: Craig McClanahan (was: Struts Developer Mailing List)
> Need More Flexibility Setting/Getting ActionForm Properties
> -----------------------------------------------------------
>
> Key: STR-311
> URL: http://issues.apache.org/struts/browse/STR-311
> Project: Struts Action 1
> Type: Improvement
> Components: Extras
> Versions: 1.0 Final
> Environment: Operating System: All
> Platform: All
> Reporter: Erik K. Worth
> Assignee: Craig McClanahan
> Priority: Minor
> Fix For: 1.1 Family
>
> AltoWeb, Inc. would like to use the org.apache.struts.action.ActionForm as a
> hash table of properties rather than a canonical bean. A hash table approach
> would be more efficient for us and we would not have to generate as much code
> (the form beans). The current Struts framework does not allow us to do this
> without changing the code because the ActionForm is accessed and updated
> using
> static utility methods that we cannot overload or extend (e.g. RequestUtils,
> PropertyUtils, BeanUtils).
> At this point, it looks like it is relatively easy to populate the ActionForm
> from a request by overloading the processPopulate method in the ActionServlet
> class. However, it is not easy to populate a servlet response because so
> many
> of the tags use the static getProperty method in BeanUtils to pull
> information
> from the ActionForm. Therefore, we request some type of extension mechanism
> that allows us to customize the way properties are accessed and mutated in
> the
> ActionForm.
> We would like to have a simple way to change this behavior without code
> changes
> to the struts code, or with limited code changes.
> Ideally, we thought of subclassing some classes or registering a class that
> does the mapping to beans (what PropertyUtils does today). This way, we can
> use
> the struts code without changing it.
> It is possible to have one utility class that is loaded by the Servlet or the
> web application by name to do all the mappings.
> Another way is to make sure that all the property settings go through one
> class
> that we can modify. In that case the changes to the struts code will be
> limited
> to one class only.
> It is possible to change the BeanUtil class behaviour today. We do not like
> this approach, because this class is part of commons package and is not
> directly part of struts. What this means is that other apache code (and our
> code as well) might try to use this class. Therefore it is better that the
> mapping is done by a single struts class that can delegate to the BeanUtils
> class.
> So the options are:
> 1. Overloaded functions (does not require struts code modification)
> 2. Registered utility class (does not require struts code modification)
> 3. A single mapping class that delegates to BeanUtils (Requires one struts
> class modification, does not require common libraries modification).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
