On Wed, Jun 02, 2010 at 07:03:37PM -0400, Mike Caron wrote:
> On 02/06/2010 7:02 PM, James Paige wrote:
>> On Wed, Jun 02, 2010 at 06:44:30PM -0400, Mike Caron wrote:
>>> On 02/06/2010 5:52 PM, James Paige wrote:
>>>> Is this an accurate description of what Rpath is supposed to do?
>>>>
>>>> node = Reload.RPath(doc, "/party/slot[3]/stats/stat[0]/max")
>>>>
>>>> Which would look in the root node for a node named "party",
>>>> then look in the party node for a node named "slot" with int value 3,
>>>> then look in the slot node for a node named stats,
>>>> then look in the stats node for a node named "stat" with int value 0,
>>>> then look in the stat node for a node named "max" and return it
>>>>
>>>> If that is indeed what RPath is supposed to do, I feel up to the task of
>>>> implementing it.
>>>>
>>>> And if that is NOT what RPath is supposed to mean, then I still feel up
>>>> to implementing it, but I will call it something different :)
>>>
>>> Almost. RPath is intended to mimic XPath, which would interpret your
>>> example as:
>>>
>>> Match the root node named "party", then
>>>   Match the third sub-node named "slot", then
>>>    Match the first node named "stats", then
>>>     Throw an error, because indicies are one-based, but if it was a one,
>>>     Match the first node named "stat", then
>>>      Match the first node named "max"
>>>       Return this node
>>>
>>> To do what you suggest, the expression would look like:
>>>
>>> party/slot[.="3"]/stats/stat[.="0"]/max
>>>
>>> And match it against the document root, whatever it may be. Explanation:
>>>
>>> 1. A leading slash matches the *document*, not the root node. (Actually,
>>> in XML, there's a hidden node above the first tag. The leading slash
>>> matches that)
>>> 2. The dot represents the "current" node
>>> 3. The expressions inside the brackets are like WHERE clauses in SQL
>>> 4. A number by itself means the Xth node.
>>>
>>> You can do stuff like
>>>
>>> no...@foo="bar"]
>>>
>>> Which matches "node" who has an attribute "foo" whose value is "bar",
>>> and is the intended way to match nodes (Incidentally, this is why I
>>> reserved the leading @ for attributes converted from XML).
>>>
>>> So, where does this leave RPath (which I have not been describing so
>>> far)? I suggest we stick closer to XPath, but perhaps with some
>>> limitations:
>>>
>>> 1. XPath allows a bunch of pseudo functions inside the brackets, things like
>>>
>>> node[next(.) == "foo"]
>>>
>>> Which would match "node", whose next sibling's value equalled "foo". We
>>> don't need that.
>>>
>>> 2. Allow matching based on children alone, so we don't need . to mean
>>> the current node.
>>>
>>> 3. Recommend that people don't use the content of the node itself to
>>> distinguish between similar nodes. Use children for that. (Or, better,
>>> give the nodes distinct names)
>>>
>>> If you need clarification, let me know (or pull me into IRC or something)
>>>
>>
>> Okay. Sounds like RPath is a lot heavier than what I have in mind
>>
>> I will continue with my simplified implementation, but I will call it
>> something else to avoid confusion.
>>
>> Probably Reload.Ext.NodeByPath
>
> Maybe, but really, my entire email could probably have been distilled  
> into the following sentence:
>
> "Correct, except I would recommend that [3] means the third node, not a  
> node whose value is 3".

The reason I don't want to do that is because of sparse arrays.

For example, when I write the globals into the rsav file, I only write 
the non-zero values.

Each "global" node has a value which is the global id number, and a 
child node named "int" which has its integer value.

So I want "/script/globals/global[47]/int" to give me the node 
containing the value for global ID 47, not the 47th global saved in the 
file.

---
James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to