<spring:bind> and relative paths

[Jörg Heinicke]

At the moment <spring:bind> only allows absolute paths to objects registered in the model. <spring:nestedPath> allows only an abbreviation of this path. I wonder why it is not possible to set something like a relative path. This would enable "real" iterating over collections as you would no longer need to rely on indices. So it would also enable iterating over non-indexed collections like maps.

<c:forEach items="${collection}" var="collEntry">
  <!-- @newPath refers to @var in c:forEach -->
  <!-- @var contains the name to refer to this context,
            might be superfluous -->
  <spring:newPath var="localName" newPath="collEntry">
    <tr>
      <td>
        <spring:bind path="localName.key">${status.value}</spring:bind>
      </td>
      <td>
        <spring:bind path="localName.value">${status.value}</spring:bind>
      </td>
    </tr>
  </spring:newPath>
</c:forEach>

This would be ways cleaner than the code I found in SPR-52 or in the thread "Error while accessing collections". Of course it introduces issues like identifying the elements and refinding the same one. But I wonder if those would not be solvable.

It would enable the usage of <c:forEach> as it was supposed to be used and it would match similar concepts in XSLT (XML/XPath).

Jörg

[Jörg Heinicke]

I found another use case where <spring:bind> as is breaks standard <c:forEach> usage:

This one should work (typed it here, without testing):

<c:forEach items="${model.items}" var="item" varStatus="loopStatus">
  <spring:bind path="model.items[${loopStatus.index}]">${status.value}</spring:bind>
</c:forEach>

Having a list directly as command object works with <c:forEach> but breaks in <spring:bind>:

<c:forEach items="${items}" var="item" varStatus="loopStatus">
  <spring:bind path="items[${loopStatus.index}]">${status.value}</spring:bind>
</c:forEach>

This behaviour is not really understandable. I'd need to introduce a DTO just for storing the list.

This sample is not really an argument pro <spring:newPath>. It just shows where <spring:bind> is not usable despite <c:forEach> works. <spring:newPath> would be a nice work around for it as I could bind the item to a localName.

Jörg