> From: Luc Saffre <luc.saf...@gmx.net> > Sent: Tuesday, October 4, 2011 4:01 AM > > > > No need to be sorry at all. First, your report will help me understand a > > bit more how users set up and use generateDS.py. Second, I just now > > looked at the code in generatedssuper.py that is included in the > > distribution. It's out of date. It should include default > > implementations of all those inherited methods (gds_format_string, > > gds_format_integer, etc.), but does not. I'll fix it. So, thanks > > for alerting me about that. > > > > Unless you have explicitly added code to generatedssuper.py, you do > > not want in to be found. That is, when you run or import a > > generated module, you do not want that module to be able to import > > generatedssuper.py. So, the question is: how do we prevent that > > import from succeeding in your case where you have put the directory > > in which you have unrolled generateDS-2.6a.tar.gz on your > > PYTHONPATH or sys.path. > > > > One possible solution is for me to "hide" generatedssuper.py in a > > subdirectory in the distribution. An alternative solution is to get > > rid of generatedssuper.py in the distribution altogether and then, > > in the documentation, to tell users who want to use it to create > > their own by copying and pasting class GeneratedsSuper from a > > generated module. That has the added benefit that I would not be > > able to forget to update a separate generatedssuper.py when I make > > changes to the boilerplate for class GeneratedsSuper, as we have > > just learned that I am likely to do. > > > > I like the second solution better. What do you think? > > Yes, get rid of it altogether and just give an example in the docs.
Luc - Done. I removed it and I modified the documentation. > > But here's a third solution: extending the User Methods module to define > this optional class. For example a global variable SUPERCLASS. > This would have the advantage that you can specify at the command line > whether to use a custom generateds superclass. This implies of course > that overriding happens at the code generation. Currently it might > change "at runtime", each time the generated modules are imported. I'm > not sure whether this is an intended behaviour. Sounds like an interesting and innovative solution. But, I think I'll wait until someone has a need for this. If you have that need, let me know. In the meantime, hopefully the solution using GeneratedsSuper is enough. > > > I'll try to answer your question about xs:any tomorrow. >From a separate email: > Here is another beginner's question (i'm just getting started with XSD > and XML). > > Still trying to generate XML for a SOAP request that obeys to > http://code.google.com/p/lino/source/browse/lino/utils/bcss/XSD/SSDN/SERVICE/SSDNREQUEST.XSD > > A ServiceRequestType has children 'ServiceId' and 'Version', and the > code generated by generateDS allows me to write for example: > > service = SSDNRequest.ServiceRequestType( > ServiceId='Test', > Version='20090409') > > But ServiceRequestType has also an <xs:any> element, and I didn't find > how I can specify, in the Python code, a value for this. The > documentation speaks about <xs:anyAttribute>, but not about <xs:any>. > > How can I achieve that? Do I need to write a User Methods module? > > Thanks in advance for any hints. OK. I've read a bit about it now. Since xs:any is a wildcard, we'd have to generate code that can parse/build and export any kind of complexType and maybe any simpleType too. The generated code would also have to be able to handle single instances and multiple instances (maxOccurs="1" and maxOccurs="unbounded"). I suppose you are right. User Methods might be a way to handle that. Or, maybe a couple of new methods in GeneratedsSuper class (e.g. gds_build_any and gds_export_any) and a bit of code wrapped around around calls to those methods in the buildChildren and exportChildren methods in classes for complexType elements that contain an xs:any child. Give me a day or two to think about it. Maybe I can write a sample of the code we'd generate, and then we can evaluate it and discuss it. - 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
