On Sun, Nov 13, 2011 at 22:31, Dave Kuhlman <dkuhl...@pacbell.net> wrote:
> >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.
Yes.
> 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?
Yes - to be specific, I am proposing that the lxml DOM node gds_build_any
would receive would be the node for which it will construct an object,
unlike now, where it receives the node which is the parent of the node(s)
for which it will construct an object.
> So,
> gds_build_any() would always be responsible for converting one node
> into one instance of a generated Python class. Agreed?
>
Yes, exactly.
> 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.
Congratulations!
> But, it means that I might
> be a bit slow with this fix. I'll work on it as soon as I can.
>
>
Do you use a code generation system to generate the generateDS script?
Whether or not you do, I would be happy to attempt to incorporate the
changes - do let me know if there is a method beyond directly hacking the
release files.
Best,
Marcin
- 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
>
>
--
Marcin Tustin
Tel: 07773 787 105
------------------------------------------------------------------------------
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
