> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 16, 2002 10:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Subclass Struts tags to work with JSTL?
>
>
> >>>>> "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.
Back around the time that Craig suggested the "var" attribute, I expressed a
preference for using parallel RT and EL taglibs:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg05792.html
As a recap, the reasons I prefer this approach are:
a) We can make any attribute that can accept an RT expr today accept an EL
expr. This will give us more flexible EL-enabled tags while not confusing
the user with a mixture of RT attributes and EL attributes on a single tag.
Of course, where the RT tags have n/p/s today, the EL tags would have a
"var" attribute instead.
b) It matches the approach taken by JSTL itself, with parallel RT and EL
taglibs.
By the way, a good reason to use the name "var" for the n/p/s attribute is
because that is what JSTL uses for the equivalent functionality. Consistency
is good! ;-)
--
Martin Cooper
>
> >> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
