> But what about elements with attributes, nested elements AND/OR text
> values?
It's recursive.
>
> What does:
>
> <element attribute="blah">text</element>
>
> Look like?
I don't think that is handled in the current code. If you have
attributes, you'd need to have nested tags (or nothing). I could add a
conditional that if you have attributes and no child tags, the text goes
into a key called 'text'. But, I hadn't really considered it before :)
>
> And what does a nested structure like this look like as a hash:
>
> <elements groupName="blah">
> <element id="1" type="blah1">text1</element>
> <element id="2" type="blah2">text2</element>
> </elements>
>
> I would expect something similar to...
Close. Since there is only 1 'elements' tag, it is not an array. Also,
having a mixture of text and attributes isn't yet handled.
I'll just rewrite your example to be what it would be currently:
>
> {
> elements:
> {
> groupName: "blah",
> element: [ 'text1', 'text2' ]
> }
> }
But, if those elements didn't have 'text1' or 'text2', then the hash
structure from the attributes would've been created. But, now that I
think about it more, having an array all the time makes more sense. I
did it the current way so that tags that only had text in them would not
be arrays, but I should change it so that if there are nested tags, it
stays an array.
>
> ...but you'll have to have some way to handle cases where an attribute
> of "TEXT" is supplied, etc...
>
> ...you might have to append your hash object names with something to
> indicate if the name/value pair represents an attribute, element, or
> text node.
>
No, I don't think I'd want to do that. If I cared about whether they
were attributes or elements, I'd just use regular XML functions to get
to what I needed. This is meant basically to just convert to a usable,
hierarchical data structure.
> Lol, it seems if you take this far enough you might as well just stick
> with XML...
Yeah, I agree. I'll probably add the part to put the 'text' in they key
'text' if there are attributes already defined, but beyond that I don't
want to extend the scope.
As always, great input. Thanks.
Greg
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
