>>>>> "David" == David Karr <Karr> writes:

    David> I'm asking this here first, to discuss the technical issues.  If it appears
    David> to be feasible, I'll ask a similar question on the user list, and then
    David> perhaps write a bug report.

    David> Presently JSTL tags can't easily access DynaActionForm objects.  I haven't
    David> used these much, but I would assume they're reasonably widely used.  How
    David> important do you think it is for JSTL tags to be able to access properties
    David> of these objects?

    David> I believe there's a simple change we could make to DynaActionForm to allow
    David> access to them from JSTL tags.  Since DynaActionForm doesn't present a
    David> strict JavaBeans interface to its properties, you can't access them
    David> normally.  However, the property values are stored in a HashMap in the
    David> DynaActionForm.  The JSTL EL syntax can access hashmap entries.  So, if we
    David> simply added a standard JavaBeans accessor for the HashMap, then the JSP
    David> programmer could access these properties through a syntax like this:

    David>   value='${actionForm.dyna["foo"]}'

    David> for the "foo" property of the "actionForm" DynaBean.

As a proof of concept, I've verified that just by adding the following to the
DynaActionForm class:

    public  Map   getMap() {
        return (dynaValues);
    }

along with the following pre-Action code:

        dynaActionForm.set("foo", "alpha");
        dynaActionForm.set("bar", "beta");

The following JSP code:

  <c:out value="${dynabean.map.foo}"/>/<c:out value="${dynabean.map.bar}"/>

prints out "alpha/beta".

I've considered whether it would be better to file an enhancement request for
BeanUtils, to modify the "DynaBean" interface, or whether to modify (file the
enhancement on) the Struts DynaActionForm class.  The former would make the
change more widely applicable, which is both the good news and the bad news.
Changing an interface would require at least all the top-level classes
implementing the interface to now implement that new method.  Alternatively,
the method could be added on just the BasicDynaBean, although I don't know
exactly what the inheritance tree down to DynaActionForm looks like.  Since
Introspection operates on the actual type, it doesn't necessarily have to be on
the interface, just the highest level class.

On the other hand, changing DynaActionForm might be easier politically.  I
posed a question about this on the commons-user list today, although the
response was polite, they appear to be planning new features in this area that
cover a much larger scope than I care about.  They may not want to go in two
directions (even though this could be a very simple change).

If only DynaActionForm is changed, however, is there any likelihood someone
will want to use a plain DynaBean with this?  One person who was looking for
this feature (who thought it was already supported in the JSTL) used as his
example JSP scriptlet code using plain BasicDynaBeans.

Any thoughts?

-- 
===================================================================
David M. Karr          ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to