On Wed, 27 Mar 2002, Henri Yandell wrote: > As far as I'm aware, the string and regexpr taglibs will not go into a > future release of the jstl (I don't think any apache taglib can go in > that direction??). > > However, the JSR people/Sun may create their own taglib specification > for string and taglib 'functions' which may or may not bear functional > similarity to the current jakarta ones. > > I could be a long way wrong though. I'm not a JSR member or anything. > Just my tuppence from how the JSTL has currently worked. I think up to > this point could be an answer for any 'Will XXX go into JSTL?' > question.
This is a good description of the process. Essentially, the JSR-052 group can continue to evaluate what areas of functionality are appropriate for versions of JSTL that follow 1.0. As part of this evaluation, the offerings in Jakarta Taglibs -- along with other vendors' libraries, assuming they're interested in contributing -- will typically be studied and discussed. As an example, this is what happened with the database (SQL) and i18n/formatting tags in JSTL 1.0. > This brings one issue in, which is adding Regexp to the JSTL makes the > JSTL 1.4 specific. So maybe we'll see this in a future in which Java > servers are at least 1.4. In principle, the back-end implementation can be divorced from the spec. The JSTL spec wouldn't ever likely require that a particular feature be implemented by JDK 1.4 regexps, the StringBuffer class, etc. -- though it would certainly be reasonable to specify a tag as behaving "with the same semantics as StringBuffer.replace()" or whatever. But we wouldn't have to depend on JDK 1.4 to introduce regexp-like functionality; instead, we'd simply want to make sure the RI implements the behavior without depending on JDK 1.4. (And speaking practically, this wouldn't be too much trouble for nearly any string-related functionality I can think of.) JSTL 1.0 is essentially feature-complete, so string/regexp support won't be included in the first version. But if people on this list are inclined to think that it would be useful to standardize this functionality, it's certainly realistic to consider it for the next version of JSTL. I encourage people who are interseted to mail [EMAIL PROTECTED] -- Shawn Bayern Author, "JSP Standard Tag Library" http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>