JXPath and java.util.List access

[Simone Gianni <si...@apache.org>]

Hi all,
in JXPath it's possible to access XML documents or collections (better
if they are Lists) using the common [index] syntax. It's also possible
to use some more complicated selections, like [position() < 10] or
[field = 'something'] and so on.

So, if I have an xml file made like this :
<friends>
  <friend>
    <name>..</name>
    <surname>..</surname>
  </friend>
  ...
</friends>

I can write /friends/friend[1] to get the first friend. But if i have a
bean like this :

  public List getFriends();

  class Friend {
    public String name;
    public String surname;
  }

I have a different syntax :

/friends[1]

The first problem is that it introduces a different syntax for what is,
in the end, the same structure.

Anyway, this should be unambiguous, since /friends always returns a
collection

The real problem happens when I don't have the getFriends method, but
I'm working directly on a List. In simple XPath I could write *[1] to
get the first element, while in this case * returns no all friends, but
pointers to all the PROPERTIES of my friends, so in this case *[1]
points to the name of the first friend, while *[2] points to the surname
of the first friend and so on.

At the same time, "." returns the collection, and ".[1]" actually
returns the first friend (which i don't think is correct XPath), but
since I believe this is simply a side effect, .[position() < 10] does
not work, while *[position() < 10] returns names and surnames of first 5
friends.

IMMO the only solution for collection access would be to use an
intermediate level (the "friend" element in the XML) so that i can write
friends/friend[1] to obtain the first element of the collection,
friends/*/name to obtain all the names, friends/* to obtain all the
friends and so on ... but this would obviously break any kind of
compatibility with all the existent stuff.

In practice, this is preventing current cocoon forms binding to operate
on a collection directly (without intermediate beans) if not using the
strange sideffect of .[1], am I missing something or there is no
in-place solution to this problem? Is the idea of an additional
"compatibility" level (/friends/*friend*[1]) completely wrong?

Simone

-- 
Simone Gianni

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org