msg4 {
seancharles[+],
posted: 11.27.03 8a•-,
top [^]
}
Hello,
I downloaded an earlier version that worked but today I downloaded it again to show somebody else and it didn't work! It took me a few minutes in the debugger to spot the difference... as published the code *can't* work because there are two calls to buildObject() which should be calls to makeObj() to make it work recursively.
If this has been mentioned elsewhere than I apologise in advance.
Thanks for a very usefule site.
Sean Charles
msg5 {
JasonM[+],
posted: 11.27.03 8a•-,
top [^]
}
Thanks for the comment... I was just tweaking it and forgot to change the names back...
msg6 {
philip_saa[+],
posted: 04.05.04 11a•-,
top [^]
}
Here is what I've been using to work around the (_type = array).
msg7 {
JasonM[+],
posted: 09.30.04 6a•11.08.04 10a,
top [^]
}
The type = "_array" is there for this purpose, otherwise there's no need to use it.
(of course the example from Philip_Saa works great, this example is really just a bit easier to read for the noobs out there, whichever you understand best use that. I'd recommend philip_saa's)
I would really appreciate if I was able to cicle the objects created by your prototype, without dealing with the "detect if it's an array" workarounds. I mean, it's ok to detect it if you have few levels of nidification, but when you have many of them it starts to be more time consuming.
Definitely I would really prefer to have arrays in any case, even if some might be populated only with one item inside.
PS:
thanks for your well formed and extremely useful prototype.
;-)
msg9 {
JasonM[+],
posted: 11.08.04 10a•-,
top [^]
}
Do you have an example of your case...?
msg10 {
indivision[+],
posted: 11.08.04 10a•-,
top [^]
}
I think what he means is that it would be easier to skip detecting whether or not the data was an array. So, if there was only one node, it would be an array with one piece of data rather than an object.
Yes indivision, it's exactly what I wanted to say.
My case was a news archive based on a XML, where I had a root node "year", the child "month", the child "day" and the child "hour". Each final news node had other nodes like "pictures", "pdf_version", "links", ecc. This meant that I could have not just cycled in the same way all the objects created: I had verify which ones were array and which ones were objects, beacuse a different sintax is required in order to access them. I had to verify each node: if in a year there was one or more months, if in a month there was one or more days, if in a day one or more hours, if in a news one or more pictures, one or more pdf, one or more links...
This is just an example, but I think that this could be quite common. If I imagine a catologue, with different brands, product lines, product types, product details, infos, ecc. I definetely would like to skip the detection process to see if I have one or more nodes in each case.
Thank you jasonM for asking and for taking time for going further with your "must-have" prototype.
//-------------------------------------------------------------------------------------------//
// THIS IS HOW I HAD TO WRITE THE CODE FOR 3 CICLES:
//-------------------------------------------------------------------------------------------//
//-------------------------------------------------------------------------------------------//
// THIS IS HOW I WOULD LIKE TO WRITE IT
//-------------------------------------------------------------------------------------------//
msg13 {
JasonM[+],
posted: 11.08.04 3p•11.21.04 1p,
top [^]
}
** Well *I could* implement this in the method by providing a paramter flag which specifies that ALL the nodes are to be created as Arrays.
Since the process would have no (safe) way of knowing that the node was "supposed" to have a series of values instead of one.
The trouble with this is it messes with all your node addresses...
root[0].mybranch[0].mytwig[0].myleaf[9]
not much fun...!
** The other alternative which has just struck me is to provide all the list nodes in advance, e.g. something like...
I'd be interested to hear which people would think are more helpful...
**
I've been intending to add dynamic datatyping for the method too, so perhaps I can add these to the method at the same time.
msg14 {
indivision[+],
posted: 11.08.04 4p•11.08.04 5p,
top [^]
}
That's a good point about the messiness of item[0].subitem[0] etc.
Here are some protos I've been using to get around the problem:
So, instead of using this syntax (which doesn't work if there is one node):
You would use:
It's a little more code, but it saves writing additional array parameter checks in loops where there may be several or only one node.
While I'm here, here is another proto that loads an XML file into an object, runs the makeObj proto on it and then executes a designated function:
Syntax for this: getXML("myXMLfile.xml","myDataObject",myFunction,[p],[o]);
p and o are optional parameters if the function needs to be applied to an object with parameters.
It might be already clear that I'm a fan of the array sintax, but I think it's for a good reason: the power of cycling blindly even the most "branching" structure. JasonM, I'm voting certainly for your first option (a flag which specifies that ALL the nodes are to be created as Arrays), because in this way I could use it even without knowing how is formed the XML that I'm going to parse.
As an heavy user of your prototype, I can say that the reason why I love it is the chance to forget the tedious process of parsing XML manually and also the XML itself. I mean that with makeObj I don't even look how the XML is generated by back-ends, by software engineers or other people working on the same project. I just parse it and use the parsed objects.
I would be very happy if I could cicle the parsed objects without dealing with the "detect if it's an array", neither thinking in advance which node should be transformed in list and which not. Thanks again JasonM.
PS
Thanks indivision for your additional prototypes. I will use them while waiting the new JasonM's XML.makeObj() (super-optimized).
:-)
msg16 {
JasonM[+],
posted: 11.09.04 2a•-,
top [^]
}
Thanks Indivision, those are some excellent proto's...
(more from me soon, v.busy right now)
msg17 {
max0matic[+],
posted: 11.23.04 9a•11.25.04 3a,
top [^]
}
I did write XMLSA... that does both ways XML->Obj->XML
But somethimes this is to much and I didn't update it for ages..
anyway... I found this little proto usefull but I tweaked it a little
with my knowlege gained on the XMLSA development...
so check this out:
- added Array notation in any case
- removed _type no need for that anymore
- grouped all attributes under "attributes" so nodenames and attribs can have the same name
- added resolver to acces first Array element if none is given
- added the proto to XMLNode rather then XML
- renamed it to makeXMLSA so things don't get messy
Okay so what's possible now?
Let me give you some examples...
lets assume you have a xmlfile like this:
Now some example to acces the data:
let me know what you think...
msg18 {
max0matic[+],
posted: 11.24.04 11a•11.25.04 3a,
top [^]
}
Even more optimisation:
In this version you can use a noRoot flag to avoid above problem:
portfolio = new XML(xmlString).firstChild.makeXMLSA();
equals portfolio = new XML(xmlString).makeXMLSA(true);
this is not final... but works 100% I say not final because it would be better to put _mxp and _mxr in
a own prototype as the are not related in any way to XML as we are
creating a object structure the hole tree could be embed in a own
class spawned (template-pattern) from Object.
Anyway.. this is what I did in XMLSA but maybe we should keep things
simple here :-)
msg19 {
b0b[+],
posted: 12.07.04 8a•12.07.04 8a,
top [^]
}
In the latest version this line always returns undefined for me... Even with your example code.
I changed that whole loop to:
and i added in:
Let me know if I'm crazy or if there's a better way...
--r
msg20 {
max0matic[+],
posted: 12.07.04 9a•12.07.04 9a,
top [^]
}
Rather then using a sizeOf I would suggest to always build the attributes child
this makes things faster and less dependant...
regards
Max
msg21 {
JasonM[+],
posted: 02.02.05 3p•02.02.05 3p,
top [^]
}
It's a terrible place to do this I know, but I have 3 GMail invites to get rid of, just pop over to my blog and post a comment if you need one...
(and apologies for being so horribly off topic!)
www.mentalaxis.com/blog
msg22 {
livingeachday[+],
posted: 04.12.05 12p•-,
top [^]
}
so i've noticed with this code that if i'm parsing element nodes with no siblings
that the code chokes and returns nothing for that particular node values...