I've made several fixes in response to several messages on this list. I aplogize for being a bit slow.
Here are notes from the README: Version 2.7b (11/25/2011) * Fix for xs:any in buildChildren in an element defined with no other children so that we do not generate "else:" clause without an "if ...:". Thanks to Keith Robertson for help with this. * Change for xs:any in buildChildren (when maxOccurs > 1) so that the gds_build_any() method always, consistently takes a single *child* node as input and returns a single built object. Thanks Marcin Tustin for guidance with this. * Fix for element definition containing an anonymous xs:simpleType. I'll release a new version in a few days. In the meantime, you can find a patched version that contains these fixes here: http://www.rexx.com/~dkuhlman/generateDS-2.7b.tar.gz And, here are a few more notes about these changes ... Keith Robertson wrote: >I just tried 2.7a with some schemas from dmtf.org and it started >producing classes with broken if/else conditions. 2.6a doesn't appear to >have this problem. Is there some new option that I'm missing? > >Command: >.../generateDS-2.7a/generateDS.py -o ovfenvelope.py dsp8023_1.1.xsd > >Broken Auto-generated Code: > def buildChildren(self, child_, node, nodeName_, fromsubclass_=False): > else: > objs_ = self.gds_build_any(node, 'File_Type') > if objs_ is not None: > self.add_anytypeobjs_(objs_) Oops. All my test cases had additional plain (not xs:any) children. I've added a fix so that for above, we will now generate: def buildChildren(self, child_, node, nodeName_, fromsubclass_=False): objs_ = self.gds_build_any(node, 'File_Type') if objs_ is not None: self.add_anytypeobjs_(objs_) Thank, Keith, for letting me know about this one. Marcin Tuscin wrote: > I've been playing around a little more with generateDS, and I've > found that it has generated a fairly large number of classes that > can never be instantiated, because they have a syntax error (see > line 3472 in the attached incorporation.py). Generated from the same > schemas I have been working with, as before (also attached, for > reference). Marcin - OK. Looks like this problem is triggered by an xs:simpleType. In an element declaration containing an anonymous xs:simpleType, we were generating the following: def __init__(self): self.valueOf_ = valueOf_ I've made a fix so that now we will generate this: def __init__(self, valueOf_=None): self.valueOf_ = valueOf_ > > 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. OK, now the new version (2.7b) generates a buildChildren method for a complexType containing xs:any that (1) passes the *child* node to gds_build_any() and (2) expects gds_build_any() to return one object. When you've had a chance to look at this, could you please let me know whether that patched version (2.7b, mentioned above) generates this code correctly. Thanks, Marcin. I appreciate your help. - Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
