> -----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]>

Reply via email to