http://issues.apache.org/bugzilla/show_bug.cgi?id=36794
I just posted the above enhancement request (with a patch to implement
it, of course ;-). This adds an external dependency on CGLIB; I don't
know if that will fly, but personally I think the benefits are worth it.
Read on to see if you agree:
Summary: remove the need to use xxx.map['property'] syntax with
DynaActionForms
Motivation: apart from it being bothersome to have to use a special
expression syntax for working with DynaBean based action forms, it also
makes life rather painful when creating re-usable components that
interact with form beans. While this isn't a common requirement for
straight JSPs, users of JSP 2.0 tag files are much more likely to run
into this. With the special-syntax requirement, tag files (and JSPs)
must go to additional effort to work with both dyna beans and regular beans.
Result: DynaBean based action forms can be accessed in JSPs and tag
files exactly the same as regular beans. There is no longer any need to
use the .map['property'] construct except where the dyna property names
are grossly non-compliant with JavaBeans naming conventions (for
example, property names containing spaces, which are currently allowed!).
Here are some examples of things that are equivalent with this patch
applied:
${MyForm.map['someProperty']}
${MyForm.map.someProperty}
${MyForm['someProperty']}
${MyForm.someProperty}
<html:input property="map['someProperty']"/>
<html:input property="map.someProperty"/>
<html:input property="someProperty"/>
${MyForm.map['indexProperty'][0]}
${MyForm['indexProperty'][0]}
${MyForm.indexProperty[0]}
${MyForm.map['mapProperty']['something']}
${MyForm['mapProperty']['something']}
${MyForm.mapProperty['something']}
Impact: the patch requires an additional external library (which is
licensed under the terms of the ASL 2.0) but otherwise there should be
no significant impact. The existing property access syntax is preserved
unchanged, so existing JSPs / tag files / code will continue to work
unchanged. The only possible issue I'm aware of so far would be in the
case of DynaActionForm sub-classes which already define getter and/or
setter methods for one or more properties declared in struts-config.xml.
If this proves to be a problem, it would be easy to make the code detect
this situation and not attempt to generate those methods dynamically.
Notes: achieving the same thing without modifying Struts Core is
somewhat non-trivial and cannot be done transparently. Some small code
changes in Struts Core would allow this functionality to be made
available as an extension (in contrib or as a seperate project on SF.net
or something). If adding a dependency on CGLIB is considered too high a
price to pay, we can discuss the options for making that possible ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
