> Subject: GenerateDS question
> Date: Tue, 4 Feb 2014 09:05:24 +0100
> From: Mikki Weesenaar <mikki.weesen...@schange.com>
> To: dkuhl...@rexx.com
>
> Hi Dave,
> Currently I am use your (great!) software and found some difficulties.
> But these might lead to improvements to your software :-)
> I am using a xsd (~120KB) to mold the response of our application, in a
> Python model. And what I found out is that certain xsd-elements (in
> this case SoftLink/s) are used a couple of times. Maybe it could be an
> improvement to combine such types together (which is possible in this
> case, since these xsd-elements all have the same properties etc.
> Python classes generated:
Mikki,
This sounds like an interesting idea. I'm wondering how often it
would be needed. Don't those extra classes indicate redundancy that
should be eliminated? Or, are they there for possible future use?
I'm also wondering how we'd control it. For example, we'd want to
be able to specify exactly which classes should not be generated.
I believe I have a fix (if I understand this issue correctly). gDS
has a facility for renaming types, and thereby, the classes that
they generate. Basically, you give gDS a dictionary that maps
source names (the names of elements/types in th XSD) onto target
names (the names of classes that are generated). If we map
SoftLinkType158, SoftLinkType227, etc all to SoftLinkType, then gDS
will only generate SoftLinkType (and will *not* generate
SoftLinkType158, etc). Plus, all references to SoftLinkType158
(SoftLinkType227, etc) will use SoftLinkType, instead.
Does that seem like what you are suggesting?
The mapping dictionary, by the way, can be given in a file named
generateds_config.py, which must be located somewhere so that
generateDS.py will import it. See this for more information:
http://www.davekuhlman.org/generateDS.html#conflicts-with-python-keywords
That capability is actually intended for another purpose, but it
seems to work here as well.
In order for this to work, one fix is necessary, and I believe that
fix should be made anyway. I still have to do some serious testing
to make sure that this fix has not broken anything.
My preliminary, light-weight testing seems positive.
Attached is a patch file (which gives that one fix that I mentioned
above), if you want to try it. I've also attached the schema and
the mapping/config file that I used in my test.
I'll keep you informed.
Dave
>
> "SoftLinkType",
> "SoftLinkType158",
> "SoftLinkType227",
> "SoftLinkType283",
> "SoftLinkType30",
> "SoftLinkType361",
> "SoftLinkType67",
>
> "SoftLinksType",
> "SoftLinksType156",
> "SoftLinksType229",
> "SoftLinksType28",
> "SoftLinksType287",
> "SoftLinksType365",
> "SoftLinksType65",
>
> The xsd; SoftLink/s-element:
>
> <element minOccurs="0" name="SoftLinks">
> <complexType>
> <sequence>
> <element name="SoftLink" maxOccurs="unbounded">
> <complexType>
> <simpleContent>
> <extension base="string">
> <anyAttribute processContents="skip" />
> </extension>
> </simpleContent>
> </complexType>
> </element>
> </sequence>
> </complexType>
> </element>
>
> I hope to hear from you!
> Best regards,
> Mikki Weesenaar
> Netherlands
> Met vriendelijke groet / With kind regards,
> Mikki Weesenaar | Test and Integration
> Flight Forum 3200
> 5657 EW Eindhoven, The Netherlands
> [1]mikki.weesen...@schange.com | [2]www.schange.com/emea |
> NASDAQ: [3]SEAC
> Mobile: +31 (0)6 - 1559 9312
> Skype: Mikki.Weesenaar
--
Dave Kuhlman
http://www.davekuhlman.org
=== modified file 'Generateds/Generateds/generateDS.py'
--- Generateds/Generateds/generateDS.py 2013-12-31 00:11:22 +0000
+++ Generateds/Generateds/generateDS.py 2014-02-04 22:41:50 +0000
@@ -4193,7 +4193,7 @@
parentName not in SimpleTypeDict):
PostponedExtensions.append(element)
return
- if element.getName() in AlreadyGenerated:
+ if mapName(element.getName()) in AlreadyGenerated:
return
AlreadyGenerated.append(element.getName())
if element.getMixedExtensionError():
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<!-- this is the real type that we will use.
-->
<xs:complexType name="sampleType">
<xs:sequence>
<xs:element name="description" type="xs:string" />
<xs:element name="category" type="xs:integer" />
</xs:sequence>
</xs:complexType>
<!-- some excess types that we will map out
-->
<xs:complexType name="sampleType01">
<xs:sequence>
<xs:element name="description" type="xs:string" />
<xs:element name="category" type="xs:integer" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="sampleType02">
<xs:sequence>
<xs:element name="description" type="xs:string" />
<xs:element name="category" type="xs:integer" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="sampleType03">
<xs:sequence>
<xs:element name="description" type="xs:string" />
<xs:element name="category" type="xs:integer" />
</xs:sequence>
</xs:complexType>
<!-- test to ensure that reference to the mapped types use the type
that it is mapped to.
-->
<xs:complexType name="testType01">
<xs:sequence>
<xs:element name="member1" type="sampleType01" />
<xs:element name="member2" type="sampleType02" />
<xs:element name="member3" type="sampleType" />
</xs:sequence>
</xs:complexType>
</xs:schema>
print 'importing generateds_config'
NameTable = {
'range': 'range_',
'sampleType01': 'sampleType',
'sampleType02': 'sampleType',
'sampleType03': 'sampleType',
}
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
