>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 16 Jul 2002, David M. Karr wrote:
>> I don't know how much thought has yet gone into how Struts and JSTL can work
>> together. I haven't noticed much serious talk about this. If these thoughts
>> are obvious or ignorant, I apologize.
Craig> There hasn't been much talk about this on the lists. Part of that is me
Craig> trying to avoid succumbing to the "pay attention to the cool new stuff"
Craig> instead of getting 1.1 out the door :-).
I definitely agree that people working on getting 1.1 out the door shouldn't
spend any time on this. That's why it's good for me to look at this, as I'm
not one of those people.
>> It occurred to me that a straightforward interim solution would be to provide
>> tag libraries named "bean-el", "html-el", etcetera. The actual tag classes
>> would just be subclasses of the Struts tags. The way that the actual JSTL tag
>> classes are implemented makes this very easy to do.
Craig> That would certainly be one way to do it. The other alternative I was
Craig> thinking of was to add a "var" attribute to each existing tag that
Craig> supported the "name/property/scope" tuple, and allow you to use either/or
Craig> with the same tag. Of course, that doesn't really cover cases like your
Craig> example of the message tag, where you might want to use EL expressions on
Craig> more than one of the attributes.
I believe I remember you mentioning the "var" idea once, on this same subject.
Although I think the name isn't quite right (the value can be an expression,
not just a variable), I think this is also the correct approach for the
"name/property/scope" tuple. In fact, these two strategies don't conflict.
For properties which could map one-to-one to an EL value, what I did here would
be fine. For things which are represented by the "n/p/s" tuple, we would add
an attribute which would only be used when "n/p/s" is not used (perhaps checked
in a TLV class), which would be an EL attribute.
So, in the case of the derived "message" tag, instead of allowing EL values for
"name", "property", and "scope" (which would probably be silly), we could have
an (throwing out a name here) "expr" attribute to take the EL value.
>> In fact, I spent about an hour this afternoon implementing and verifying a
>> proof of concept (mostly spent updating my environment), adding a
>> "bean:el-message" tag to my local CVS of Struts. For a P.O.C., it was easier
>> to add the tag to the existing tag library, but for a real implementation, I
>> would want a separate tag library. The code for the tag is very
>> straightforward. My test derived from "MessageTag", but it could just as
>> easily (I believe) derive from "NestedMessageTag".
Craig> I think this would be a cool "contrib" thing, if you wanted to work
Craig> the tags out and host it here. That's how the "nested" tags started,
Craig> IIRC.
I will work this further and see how far I get.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
