See below.
On 29 Oct 2002, David M. Karr wrote:
> Date: 29 Oct 2002 23:16:25 -0800
> From: David M. Karr <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Accessing DynaActionForm objects in JSTL tags?
>
> >>>>> "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?
>
Sorry for the late response on this.
The standard expression language mandated by the specifications of JSTL
(and JSP 2.0) does *not* support DynaBeans. It is extremely unlikely that
any such support would ever get added into the standard, unless DynaBean
itself became a standard Java API (under the java.* namespace) in some
future J2SE version -- and I'm aware of no plans for that.
It is certainly technically feasible to create an implementation of this
expression language (and even of JSTL) that supports all of the standard
spec requirements *and* transparently supports DynaBeans. However, I
believe that this would be a disservice to the Java community at large,
because it would only work in that particular implementation of JSTL. It
would definitely not work in a standard JSP 2.0 container (where the JSTL
implementation is no longer relevant) unless the container itself was
modified -- and that still perpetuates the portability problems of trying
to support this thing invisibly.
Therefore, I'm +1 to adding a getMap() method to ActionDynaForm in Struts,
to make it possible for DynaBeans to interoperate with *standard* JSTL
tags (and, by the same token, with the standard capabilities of JSP 2.0
containers). This won't be invisible, because the expression will have to
be different, but at least it will be possible.
Side note -- the evaluator in commons-beanutils was recently
enhanced to act more like JSTL with respect to the "." operator
when the left-hand-side is a Map. Therefore, if you've got a
DynaBean "foo" with a property named "bar", either of the following
syntaxes would work in a JSTL expression to access it, assuming
getMap() was added:
${foo.map["bar"]}
${foo.map.bar}
This is still different than the expression you'd use to access
a standard JavaBean property:
${foo.bar}
but at least it's a lot closer.
However, I don't believe this change should be done in the underlying
commons-beanutils APIs, because if you are using commons-beanutils
already, you have transparent access (via BeanUtils and PropertyUtils) out
of the box, and need nothing more. And there might well be environments
where DynaBean is implemented using techniques other than an internal Map
-- it is not fair to constrain those possible implementations by requiring
them to implement a potentially costly getMap() method.
Craig
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
