Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>: > 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? >
The <h:message> and <h:messages> tags are both JSF components, so they require a JSF implementation -- but *any* JSF implementation will do, because they are standard. > 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. In this particular case, you'll note that I included <s:message> in the Struts-Faces integration library. It is a JSF component, but it has semantics like the <html:message> tag (for example, it looks things up in a Struts MessageResources object instead of resource bundles the way that the standard JSF components work). For the same reason, I included JSF-ized versions of <html:base>, <html:errors>, <html:form>, <html:html>, <html:javascript>, <html:stylesheet>, and <bean:write> in order to make transition of existing apps very easy. If there's any useful tags I missed that don't already have obvious JSF replacements, I'd be happy to add them as well. > >> > > > > > > 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 > "Superceded" is definitely true for new development. It would be unfair, though, to existing applications to drop them in a 1.x release, however, because it would prevent existing apps from being to upgrade without an expensive rewrite. > <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 ... > The STRUTS-EL docs have some useful information that will help this investigation; it documents which basic Struts tags were not included because the JSTL equivalents were there. > >>-- > >>Peter Pilgrim Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
