Community
Participate
Working Groups
Reasonable information that should be available in each iteration: a) whether this is the first iteration b) whether this is the last iteration c) the current index in the iteration ... maybe some others
Could this be solved using the XPath position() function (currently always returning '1')?
I'm not sure. For it to work, the default context for evaluation of XPath expressions within the c:iterate would need to reference the Node Set returned by the c:iterate tag's select expression (as well as the current node in the iteration). This is currently not the case. Pre-Galileo (JET 0.9.x and earlier), the default context was the source model (i.e. it was fixed). With Galileo (JET 1.0.x and later), the default context is the current object in the iteration (but without any reference to the node set from which it came). I do admit, it would be a very slick solution. You could image doing something like: <c:iterate select="/foo/bar"> ${position()} of ${last()} : ${@name} </c:iterate> (or, if you still think in pre-Galileo JET) <c:iterate select="/foo/bar" var="bar"> <c:get select="position()"/> of <c:get select="last()"/> : <c:get select="$bar/@name"/> </c:iterate> Implementation notes: To do this, API would need to be extended on XPathContextExtender, probably with an overload of pushXPathContextObject to be something like: pushXPathContextObject(Object[] nodeSet, int position) Obviously, c:iterate would need to be changed. In addition, this would ripple into the XPath engine's API, too. This is where I am most hesitant. The Java XPath APIs (javax.xml.xpath in 1.5 and later, and upon which JET's APIs are based) does not have the concept of evaluating an expression against a context object within a collection. Never-the-less, I will give this whole approach some more thought. For what it's worth, when I wrong this bug in the first place, I imagined adding an attribute to c:iterate (e.g. 'status') which would define a variable which would grant access to loop status information. Definitely not as slick as the above, but more consistent with what JSP's JSTL does