jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Bayern <bay...@essentially.net>
Subject Re: [standard] public draft comments
Date Tue, 02 Apr 2002 22:13:10 GMT

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 <c:forEach>-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 <c:forEach> already supports comma-separated Strings as 
 > "collections", why provide a separate tag <c:forTokens> that simply 
 > adds support for specifying the delimiters ? I think that flexibility 
 > should be built in to <c:forEach>, 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
<c:forEach> 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 <c:forEach> 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 <c:forTokens> a good naming convention for 
 > tags based on <c:forEach> ? I.e. if I develop a tag that iterates over 
 > e.g. files in a directory, should that be <acme:forFiles> or rather 
 > <acme:forEachFile> ? I personally prefer the latter, but the naming of 
 > <c:forTokens> 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

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 <x:parse> and <x:transform> duplicate functionality that
 > is already available via the <c:import> tag, i.e. the attributes
 > 'xmlUrl' and 'xsltUrl'. Simply relying on <c:import> would obviously
 > reduce implementation and usage complexity.

I agree that it would be nice to let <c:import> 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 <c:import> 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
<x:parse> and <x:transform>.

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 <x:parse>-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 <param> Tags. However, every taglib in JSTL uses a different 
 > <param>-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 <c:param> tags automagically. 
 > [The above would become especially attractive when - in some 
 > imaginable future - all the various param tags get merged with 
 > <jsp:param>.]

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, <sql:param> doesn't accept a 'name'
attribute.  Separately, <c:param> 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:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>

View raw message