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