Bug 187524 - <c:iterate> should provide a mechanism for determining position in the iteration
Summary: <c:iterate> should provide a mechanism for determining position in the iteration
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Jet (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Paul Elder CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-17 08:30 EDT by Paul Elder CLA
Modified: 2020-05-01 16:11 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Elder CLA 2007-05-17 08:30:42 EDT
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
Comment 1 Kristian Sons CLA 2009-09-24 05:01:54 EDT
Could this be solved using the XPath position() function (currently always returning '1')?
Comment 2 Paul Elder CLA 2009-09-30 12:35:42 EDT
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