Yeah, perhaps getXPathIndex would be better. I suppose I could make
that the real method,  and deprecate the getNodeOffset method and have
it call getXPathIndex.



On Tue, Jun 24, 2008 at 1:26 PM, P T Withington <[EMAIL PROTECTED]> wrote:
> Approved.
>
> I wonder if it could have a better name that reflects the fact that it is
> actually calculating the xpath index of the node in it's parent?
>
> On 2008-06-24, at 13:09 EDT, Henry Minsky wrote:
>
>> Change 20080624-hqm-Y by [EMAIL PROTECTED] on 2008-06-24 13:00:25 EDT
>>   in /Users/hqm/openlaszlo/trunk4
>>   for http://svn.openlaszlo.org/openlaszlo/trunk
>>
>> Summary: support datapath iteration workaround from dguide example
>>
>> New Features:
>>
>> Bugs Fixed: LPP-6282
>>
>> Technical Reviewer: ptw
>> QA Reviewer: pbr
>> Doc Reviewer: (pending)
>>
>> Documentation:
>>
>> Release Notes:
>>
>> Details:
>>
>> The example mentioned in LPP-6282 from the docs describes a workaround for
>> recomputing an xpath after it gets nulled out by the selectNext/selectPrev
>> selectors.
>>
>> + The workaround depended on a LzDatapointer.getNodeOffset, method that
>> was deprecated, and removed recently. This patch puts it back and
>> makes it public.
>>
>>
>> The deprecation comment in LzDatapointer.getNodeOffset used to say use
>> xpath "position()" operator instead, but that does not work in this
>> case because the xpath no longer exists, and the app code is trying to
>> reconstruct it.
>>
>> + This patch removes the LzReplicationManager.getNodeOffset method,
>> because it had a conflicting semantics (it takes a node pointer,
>> whereas the LzDatapointer.getNodeOffset does not), and there don't seem
>> be any callers. (Of course, that is why LzDatapointer.getNodeOffset got
>> deprecated, so maybe this will cause the same kind of trouble)
>>
>>
>> Tests:
>>
>> attached to bug report
>>
>> Files:
>> M      WEB-INF/lps/lfc/data/LzReplicationManager.lzs
>> M      WEB-INF/lps/lfc/data/LzDatapointer.lzs
>>
>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080624-hqm-Y.tar
>
>



-- 
Henry Minsky
Software Architect
[EMAIL PROTECTED]

Reply via email to