One complication here is that the selectors for moving up to the parent, or down to a child, could potentially cause you to get meaningless xpaths. selectPrev and selectNext just adjust the offset value, but if you select the parent, and your xpath was not absolute, but a fragment, like "person", it might just disappear entirely.
So in that case, it might be too confusing an API to have the xpath get updated when you call selectNext and selectPrev, but have it become null for other selectors... On Tue, Jun 24, 2008 at 11:16 AM, Henry Minsky <[EMAIL PROTECTED]> wrote: > I'm looking at a broken data example in the docs, the last example in > the page > http://labs.openlaszlo.org/trunk-nightly/docs/developers/databinding.html. > > It has some example code (broken now) which is supposed to work around the > behavior of datapath, where if you call selectNext() or selectPrev(), > the datapath's xpath is set to null. > > I am wondering if anyone is depending on this behavior, or if it would > be a good idea to > try to make the selector functions (selectNext, selectPrev, etc) > update the xpath > to be correct. That would mean for example if you were pointing to > people/person[1], and > you called selectNext, the xpath would be updates to be "people/person[2]". > > > > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > -- Henry Minsky Software Architect [EMAIL PROTECTED]
