Tree Arrays: putting XML in nested arrays

[David Bovill]

2009/1/1 Trevor DeVore <lists at mangomultimedia.com>

>
> I've never timed the overhead of filter but in my case I don't notice a
> speed hit and the structure isn't unnecessary. I use these conversion
> routines to facilitate interfacing with web services. As soon as I receive a
> response from the server I convert it to a Revolution array. If I need to
> send a request then I create an array, convert to XML and send it. Often I
> need to be able to extract an entire node and send it to a function for
> further processing. If the attributes were stored in a different branch in
> the array then it would complicate the code for doing this.


I can't see it would complicate anything - just simplify the code? To get an
attribute you'd simply prepend the path with "@attribute" rather than stick
it at the end - the bonus would be speed and less lines of code (no need for
filter). Or am I missing something?

In general I've found I can code much more quickly and end up with more
> readable code when working with the new MD arrays as opposed to the revXML
> calls.


Snap - that's one of the main use's here - I'm just looking to generalise
it. My thinking is that this exact same code could replace the
data-structures that I also use for tree-widgets (and therefore for storing
a variety of hierarchical data) - so a generic and fast treeArray data
structure could be used for both web service's (XML or JSON) and for tree /
outline widgets. That's why I'm being a bit picky about the actual data
structure, and making it as lean and fast as possible.