+1. Just keeping the functionality facts straight...
Quoting David Graham <[EMAIL PROTECTED]>:
>
> --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> > Nope. <logic:match> does substring matching.
>
> IMO, any tag that does not interact with Struts' core resources should
> live in the Jakarta Taglibs project. This allows non-Struts projects to
> benefit from the functionality while freeing Struts to focus on its core
> features. Substring matching doesn't sound like a Struts specific
> operation.
>
> David
>
> >
> > Quoting Tim Chen <[EMAIL PROTECTED]>:
> >
> > > ...
> > > <logic:match> no equalivant in JSTL 1.0 but exists String functions
> > in
> > > JSTL 1.1
> > > ...
> > >
> > > logic:match equivalent is <c:if test="${foo.bar eq 'hello
> > world'}>xxx</c:if>
> > >
> > > -Tim
> > >
> > > Peter A. Pilgrim wrote:
> > >
> > > > Craig R. McClanahan wrote:
> > > >
> > > >> Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
> > > >>
> > > >>
> > > >>> Joe Germuska wrote:
> > > >>>
> > > >>>>> > Whether the "classic" and "el" taglibs are one chunk or two
> > isn't
> > > >>>>>
> > > >>>>>
> > > >>>>>> hugely important to me either -- I would prefer that this
> > > >>>>>> decision be
> > > >>>>>> made by developers who've done more work on that code to date.
> > > >>>>>> However, I did find that when I patched
> > > >>>>>> o.a.s.t.html.JavascriptValidator, I had to go and make a
> > > >>>>>> corresponding change in the EL version. I suspect that changes
> > in
> > > >>>>>> those two libraries are going to track pretty tightly. But
> > like I
> > > >>>>>> said, I'm not pushing for this; just floating it...
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> Is there any reason that the EL tags wouldn't replace the
> > existing
> > > >>>>> tags
> > > >>>>> for Struts 2.0? Also, IMO, many of the tags can be removed
> > > >>>>> entirely for
> > > >>>>> 2.0 because they've been replaced by more powerful counterparts
> > in
> > > >>>>> the
> > > >>>>> JSTL.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> As I've been saying (a lot, it seems, lately) on struts-user, I
> > > >>>> think there are legitimate Struts JSP tags like "html:messages"
> > > >>>> that are not best replaced by JSTL. Any time Struts tools put
> > > >>>> resources in special locations in request or session scope, I
> > think
> > > >>>> it's nice to have tags which know the special locations, instead
> > of
> > > >>>> expecting people to dig in and find them. And, for example with
> > > >>>> html:messages, the message-property filtering is a useful feature
> >
> > > >>>> that would require a lot of verbose JSTL to achieve the same
> > goal.
> > > >>>>
> > > >>>> So, I'd suspect even in 2.0 there will be arguments for a small
> > > >>>> Struts taglib. But I am 100% on board with pushing people to use
> >
> > > >>>> the JSTL where it is really equivalent.
> > > >>>>
> > > >>>> Joe
> > > >>>>
> > > >>>
> > > >>> All
> > > >>>
> > > >>> +1 Some Struts tags are indeed very great.
> > > >>>
> > > >>> I also found the original <html:options> tag to really be useful
> > > >>> last year
> > > >>> at RBS generating HTML OPTIONS elements. Repeating the same thing
> > JSTL
> > > >>> <c:if> or <c:when> statment is verbose. If there not EL equivalent
> > > >>> of <html:options>, it will be on my todo list.
> > > >>>
> > > >>
> > > >> It's not just an issue of JSTL and EL-enabling Struts tags. JSF,
> > for
> > > >> example,
> > > >> has more powerful equivalents of <html:options> (<f:selectItems> --
> >
> > > >> among other
> > > >> fancy things you can make it create hierarchical option lists by
> > > >> emitting
> > > >> <optgroup> very easily), as well as equivalents for <html:messages>
> > > >> (<h:message> for a single field, <h:messages> for the general
> > messages).
> > > >>
> > > >
> > > > So I guess what you are, in fact, saying that we should be using
> > > > JavaServer
> > > > Faces or looking to use it, for 2004/2005. One question are the JSF
> > tag
> > > > actions <h:message> and <h:messages> dependent on a JSF
> > implementation
> > > > or can they be used standalone?
> > > >
> > > > Perhaps that is what we need to do as Developer. Write some kind of
> > > > feature
> > > > compatibility matrix.
> > > >
> > > > Old Tag : New Tag : Description
> > > > ==============================================
> > > > html:messages h:messages extends original behaviour and
> > > > can make it create hierarchical
> > > > option lists by emitting <optgroup>.
> > > >
> > > >>
> > > >>> I presume there are some other Struts HTML tags that are
> > favourites
> > > >>> with
> > > >>> other people too.
> > > >>>
> > > >>
> > > >>
> > > >> Likewise, the Struts-Faces integation library has JSF-componetized
> > > >> equivalents
> > > >> for some of the Struts HTML tags (including messages) to make it
> > > >> easier to use
> > > >> as a drop-in replacement. I'd be interested in hearing
> > specifically
> > > >> what other
> > > >> "favorite" tags their are, to make sure that equivalent
> > functionality is
> > > >> available to a JSF-based user of Struts.
> > > >>
> > > >
> > > > <logic:iterate> superceded by JSTL
> > > > <logic:forward> superceded by JSTL
> > > > <logic:redirect> superceded by JSTL
> > > > <logic:equal> superceded by JSTL
> > > > <logic:notEqual> superceded by JSTL
> > > > <logic:greaterThan> superceded by JSTL
> > > > <logic:greaterEqual> superceded by JSTL
> > > > etc
> > > >
> > > > <logic:match> no equalivant in JSTL 1.0 but exists String functions
> >
> > > > in JSTL 1.1
> > > >
> > > > <bean:define> replace with <c:set>
> > > >
> > > > <bean:size> we need a simple tag lib action for JSP 1.2 and JSTL
> > 1.0
> > > > to get
> > > > the size of java.uitl.Collection until there is widespread
> > > > support JSP 2.0 JSTL 1.1
> > > >
> > > > Investigation continue with rest of Beans taglib ...
> > > >
> > > >>> --
> > > >>> Peter Pilgrim
> > > >>
> > > >>
> > > >>
> > > >> Craig
> >
> > --
> > Kris Schneider <mailto:[EMAIL PROTECTED]>
> > D.O.Tech <http://www.dotech.com/>
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
