With JSTL 1.1 (JSP 2.0), you get a set of string manipulaton functions (which
Peter was referring to) that includes:
fn:contains(string, substring)
fn:startsWith(string, prefix)
fn:endsWith(string, suffix)
In addition, you also get a length function that operates on collections and
strings:
fn:length(input)
Where "input" can be: String, array of objects or primitives, Collection,
Iterator, Enumeration, or Map.
Quoting Tim Chen <[EMAIL PROTECTED]>:
> You're right (as usual ;))
> I was using the String taglib in addition to the JSTL 1.0 taglib to do
> the test. (duh)
> Although looking at it now.. there isnt any support for begin and ends
> in that neither.
>
> -Tim
>
> Kris Schneider wrote:
>
> >Nope. <logic:match> does substring matching.
> >
> >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/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
