>From: Marcin Tustin <marcin.tus...@gmail.com> >Sent: Saturday, November 12, 2011 4:13 AM >
[useful analysis snipped] > > I propose the following possible solutions. My preferred option is > the first option, numbered 3 below: > > 3. gds_build_any always receives a child, and always returns a > single object > > This way, the caller is responsible for iterating over children, and > deciding what to do with the result Marcin - Thanks much for the helpful analysis, suggestions, and code. This (option number 3) sounds reasonable to me. I believe your suggestion makes the interface between buildChildren() and and gds_build_any() more consistent, which is your goal, I believe. I'm assuming that when you say "gds_build_any always receives a child" you mean that it always receives the node (from the lxml DOM tree), right? So, gds_build_any() would always be responsible for converting one node into one instance of a generated Python class. Agreed? And, if that does not seem to work, I'll take a look and option number 4. Just last week I took on a day-job. I'm programming in Python doing mostly wxPython work. It's fun so far. But, it means that I might be a bit slow with this fix. I'll work on it as soon as I can. - Dave > > 4, gds_build_any always receives the node, and always returns a > list/iterable. > > This way, gds_build_any is responsible for figuring out any > iteration over child nodes, and the caller can choose whether to > replace its list of children with the result, append it to that > list, or even to destructure it. > > > My attached code > > The attached code consists of code generated by generateDS (with > some manual modification in envelope.py as detailed above), plus > generatedssuper.py, which is the generated code, with my > implementation of gds_build_any, and all it relies on, plus xml2.py. > > xml2.py imports the above files, and launches the generateDS > parsing/exporting code. It exists because gds_build_any uses > reflection to detect all loaded subclasses of GeneratedsSuper, from > which it extracts any member data specifications, and examines the > names of classes to detect which (probably don't) represent tags. > This information is held in a MultiDict, and each time gds_build_any > tries to build an object for a node, it uses the tag name to > retrieve a list of potential types. It then runs down that list, > testing whether the object built .hasContent_. > > Note that the multidict comes from werkzeug. Werkzeug is BSD > licenced, so if desired, it would probably be possible to paste the > code out of werkzeug. > > Please do let me know which approach you prefer to adopt, and your > thoughts on my implementation of gds_build_any. If you are > interested, I would be very happy for it to be incorporated into > generateDS. -- Dave Kuhlman http://www.rexx.com/~dkuhlman ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
