Return-Path: Delivered-To: apmail-jakarta-taglibs-dev-archive@apache.org Received: (qmail 90112 invoked from network); 2 Apr 2002 23:20:09 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Apr 2002 23:20:09 -0000 Received: (qmail 16351 invoked by uid 97); 2 Apr 2002 23:20:13 -0000 Delivered-To: qmlist-jakarta-archive-taglibs-dev@jakarta.apache.org Received: (qmail 16332 invoked by uid 97); 2 Apr 2002 23:20:13 -0000 Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tag Libraries Developers List" Reply-To: "Tag Libraries Developers List" Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 16315 invoked from network); 2 Apr 2002 23:20:12 -0000 Date: Tue, 2 Apr 2002 17:13:10 -0500 (EST) From: Shawn Bayern X-Sender: bayern@precision To: Christopher Lenz cc: jsr-52-comments@jcp.org Subject: Re: [standard] public draft comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Tue, 2 Apr 2002 18:19:55 -0500 (EST) ReSent-From: Shawn Bayern ReSent-To: taglibs-dev@jakarta.apache.org ReSent-Subject: Re: [standard] public draft comments ReSent-Message-ID: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Christopher, Thanks for the detailed comments. Here are my own personal responses. > (1) Core > > - Shouldn't the method LoopTag.getIteratorStatus() be called > LoopTag.getLoopStatus() ? Sure, this change would make sense to me. > - How about renaming the -tag 'items' attribute to 'in', > for brevity, but -more importantly- because it usually goes "for each > $foo in $bar" in languages that support for-each (AFAIK). The expert group has discussed, and may still be debating, the names of attributes. I'm not sure that using 'in' just because other programming languages have an 'in' keyword would be appropriate, but attributes like 'value' for other tags may be reviewed before PFD. > - Given that already supports comma-separated Strings as > "collections", why provide a separate tag that simply > adds support for specifying the delimiters ? I think that flexibility > should be built in to , so that page authors only need to > remember one tag for iteration. Simply add the constraint "If the > 'delims' attribute is specified, 'items' must point to a String > object" or "The 'delims' attribute will only be used if 'items' > evaluates to a String object", whatever. The rationale was that it seemed inappropriate to bloat the core tag with specific functionality. The "delims" attribute seemed to be the breaking point. Tokenization was considered important enough to warrant a standard tag, but it's probably not common enough to require each user of to see the 'delims' attribute in a table. Our tag-design principles include not trying to "overload" too much behavior in a single tag. > - On a related note, is a good naming convention for > tags based on ? I.e. if I develop a tag that iterates over > e.g. files in a directory, should that be or rather > ? I personally prefer the latter, but the naming of > suggests the first. Good question; the expert group did consider both names, but I'm not sure it meant to establish a naming convention. I defer to Pierre if he has any more specific thoughts. > (3) XML > > - I really hope that the XPath-EL is going to be updated to be as > similar to the JSTL-EL as possible. Specifically: > o The mandatory use of ${...} makes the JSTL-EL much clearer. > o Implicit objects (or scopes) access is different. The XPath-EL > uses scope:name while JSTL-EL uses scope.name. In addition the > XPath EL defines the scopes "header", "cookie" and "initParam", > all of which are not available in the JSTL-EL (AFAICT). > Frankly, I think the page author should not notice _any_ difference > between usage of the XPath-EL and the JSTL-EL, even if there are a > whole lot of implementation differences. With tags that use XPath, we are limited by XPath's syntax. We have no leeway, unfortunately, to define variable references as ${variable.property}. XPath does support variables, but a variable reference is simply a '$' character followed by an XML QName (qualified name). Thus, we can't avoid the ':' separator and can't introduce our own delimiters. We CAN, however, ensure the scopes and top-level objects match between XPath and the JSTL EL -- and this is the plan for PFD. It was just an oversight that they didn't line up completely in PD. > - Why do both and duplicate functionality that > is already available via the tag, i.e. the attributes > 'xmlUrl' and 'xsltUrl'. Simply relying on would obviously > reduce implementation and usage complexity. I agree that it would be nice to let handle all importing. The problem is that XML documents might refer to external entities (e.g., a DTD to validate against) using a relative path. In such cases, the import with and subsequent exposure as a String or Reader hides too much information from the XML parsing and transformation libraries; they won't know where relative external entities come from. Thus, we felt we needed to provide support for accessing URLs directly from within and . Having said that, there are some problems with relative references that I've recently pointed out in a private message to Pierre, and I suspect the EG will need to debate this and reach a resolution before FCS. > - I personally don't like the attribute names 'xmlText' and > 'xsltText'. Hoping that the point above makes sense (and thus the > corresponding 'xmlUrl' and 'xsltUrl' attributes get eliminated), how > about renaming them to 'source' and 'template(s)', respectively. I'm not sure I like the attribute names either, but I don't know what would be better. > - The -tag specifies two attributes, 'scope' and 'scopeDom' > for the scoped variables 'var' and 'varDom'. As usage of those two > scoped variables is mutually exclusive, there will always be only one > variable exposed. It doesn't really make sense to have two separate > attributes specifying the scope of one exposed variable, IMHO. It may be that we'll end up allowing both variables to avoid re-parsing (if an application needs both). Also, it might make sense to keep the two attributes for consistency's sake. But your point is well taken. > (4) General > > - There are a whole lot of tags that support parametrization via > nested Tags. However, every taglib in JSTL uses a different > -tag, but with always the same attribute-set and syntax. > Semantics are of course dependant on the tag its nested in. So far, so > good. I see a lot of JSTL-based custom tag libraries with a need for > parametrization though. So how about adding generalized support, for > instance a javax.servlet.jsp.jstl.core.ParameterizableTag interface > with a addParameter(String name, String value) method. Tags that need > parameterization would implement that interface, and get parameters > added by nested tags automagically. > [The above would become especially attractive when - in some > imaginable future - all the various param tags get merged with > .] Yeah. To be honest, my inclinations are the same. One problem, however, is that each different kind of parametric tag has slightly different syntax and semantics. For instance, doesn't accept a 'name' attribute. Separately, at one point needed a way to let the user indicate whether the attribute should be URL-encoded or not; we removed this, but it demonstrates a reason that it might be useful to have separate tags. Note that this doesn't argue against an interface like ParametricTag. We haven't yet seen a need to make something like this public, but fortunately, nothing in the current spec would prevent us from doing so in the future. That is, it would be easy to retrofit all of the core URL tags, FMT message tag, XML transform tag, and SQL operation tags to implement a common (potentially public) interface if a real need emerged. Though I tend to like public interfaces like this, I'm still a bit skeptical about how much the different types of "parameters" really have in common. Thanks again for the detailed comments! Shawn Bayern JSTL reference-implementation lead -- To unsubscribe, e-mail: For additional commands, e-mail: