> -----Original Message-----
> From: David M. Karr [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 18, 2002 5:40 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Status on Struts-EL
[snipped]
> One idea that Craig pointed out to me is that the JSTL
> implements the "prefixes" in JSTL expressions like
> "pageScope", "param", etc. by setting up a variable context,
> so that properties referenced from the variable context can
> be done in the EL engine. It is straightforward to set up a
> variable context for an arbitrary variable. Thus, we could
> still have the "name, property" pair, where the "name"
> attribute has the usual meaning, but the "property" attribute
> could be an EL expression, but it would be evaluated in the
> context of the explicit or implicit bean (and not wrapped
> with "${" and "}"). It's likely that I'll be using this
> strategy in some form. Hopefully Shawn can give me an
> example of how to do this :) .
>
> The problem that I can see with this strategy, however, is
> that EL expressions can be arbitrarily complex, and I'm not
> sure we can easily guarantee that the "property" EL
> expression can always be used as a request parameter name.
> In addition, there might be some confusion with specifying
> that an attribute will be evaluated with the EL engine, but
> that it would NOT be wrapped with "${" and "}".
Just FYI, the HTML 4.01 spec defines the "name" attribute of form
controls as CDATA and doesn't put any restrictions on what they can
contain, AFAICT.
That said, I personally kind of like this idea:
> Along with these ideas, I did realize another completely
> different strategy for building this library. Instead of
> trying to change "how it works" under the covers, I could
> simply implement a tag library that exactly matches the
> Struts tag libraries, but all of whose attributes are
> evaluated with the EL engine. The internal behavior of the
> "name, property" pairs would be unchanged, but attribute
> values could be specified as EL expressions in addition to,
> or instead of, rtexprvalues. This would clean up the nasty
> code I've seen people write to assemble an "on..." attribute
> value from pieces. I believe this only becomes a slight
> implementation difficulty for attributes whose type is not
> String or boolean, like the "collection" attribute of some
> tags. Since from the point of view of JSP, an EL expression
> is just a string, that wouldn't map directly to a javabeans
> set method that takes a Collection. In these cases, I
> believe I'd have to implement a BeanInfo class that specifies
> a method in my subclass, like "setCollectionExpr()" or
> something like that, which I can map into the base class
> "setCollection()" method.
--
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
