Dave,
First of all, thanks for the quick response! :-)
I already discussed with the developers that they will introduce extra
types for less redundancy.
Your fix might solve my problem, but for some reason I just generated a new
model (without the generateds_config.py or patch), with the same xsd, but
without those redundant types... -confused now-
I will try some further testing in a week or two - since I'm on a tight
schedule until then.
Thanks so far!
Best,
Mikki
On Wed, Feb 5, 2014 at 1:44 AM, Dave Kuhlman <dkuhl...@davekuhlman.org>wrote:
> > 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
>
------------------------------------------------------------------------------
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
