Well, for this upcoming release, I'm had better just put back
LzDatapointer.getNodeOffset for now, and make it public, since it
looks like people
rely on it to work around the vanishing xpath issue, and I don't think
there is any other workaround that uses
a public API.






On Tue, Jun 24, 2008 at 12:47 PM, P T Withington <[EMAIL PROTECTED]> wrote:
> There's no '..' in xpath?
>
> Maybe this is a waste of time, but I would think if xpaths were
> deterministic, there should be a 'canonical' xpath that you can compute for
> each case.
>
> On 2008-06-24, at 12:18 EDT, Henry Minsky wrote:
>
>> 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]
>
>



-- 
Henry Minsky
Software Architect
[EMAIL PROTECTED]

Reply via email to