[jira] Reopened: (STR-311) Need More Flexibility Setting/Getting ActionForm Properties

["David Evans (JIRA)" <ji...@apache.org>]

     [ 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org