Edwin,
> I was expecting that these two were properly set in the add_asset
> method. Is there a reason not to add this for all cases where
> there is a containment relation with an abstract class in the XSD?
> This would prevent having to do it manually each time...
Thanks for this interesting suggestion, although it might be
assuming more ability on my part than we are justified in expecting.
I cannot think of a reason *not* to add that code, although I
suppose I'd better study that a bit.
I'll look into it. I'll need to figure out a few things before I
can do it. After looking briefly at the existing code in
`generateDS.py`, it looks like I can follow along from the code used
to generate the current `xsi:type` code.
By the way, I suspect we'd want to do this for the setter as well,
so we'd want this added functionality in relevant `set_xxx` methods
as well as `add_xxx`.
I'll report back later. If you have more ideas about this, please
pass them along.
Question: Do you think we would want the setter (`set_xxx`) and the
append method (`add_xxx`) to always and unconditionally do this.
Or, should it be optional and controllable? For example, `set_xxx`
and `add_xxx` could both have an optional argument -- Maybe
something like this:
def set_asset(self, asset, with_type_=True):
self.asset = asset
if with_type_:
asset.original_tagname_ = 'Asset'
asset.extensiontype_ = 'WindTurbine'
def add_asset(self, asset, with_type_=True):
self.asset.append(asset)
if with_type_:
asset.original_tagname_ = 'Asset'
asset.extensiontype_ = 'WindTurbine'
Dave
On Tue, Oct 16, 2018 at 06:43:18AM +0000, Matthijssen, E.F. (Edwin) wrote:
> Hello Dave,
>
> Thanks for the fast, elaborate and clear reply. Sorry for not
> being clear. My (example) code is in the repository I listed in
> the beginning of my mail. I could have better copied some lines of
> code in my question, I now realize.
>
> You’re second option is the one I was referring to. I also tried
> the first (reading an XML, do some processing and write it back to
> XML) and that worked flawlessly (as long as I don’t add new
> instances from abstract classes.
>
> Using the debugger with the generated code, I already found the
> two relevant variables you mention (original_tagname_ and
> extensiontype_). I was expecting that these two were properly set
> in the add_asset method. Is there a reason not to add this for all
> cases where there is a containment relation with an abstract class
> in the XSD? This would prevent having to do it manually each
> time...
>
> Regards,
> Edwin
>
> Verstuurd vanaf mijn iPhone
>
> > Op 15 okt. 2018 om 22:43 heeft Dave Kuhlman <dkuhl...@davekuhlman.org> het
> > volgende geschreven:
> >
> > Edwin,
> >
> > Good to hear from you.
> >
> > You did not mention how you created the instances of the Python data
> > binding classes (generated by generateDS.py from your schema). Did
> > you (1) create them by using those classes to parse an XML instance
> > document and then export it to XML? Or, (2) did you create those
> > instances manually by writing your own Python code?
> >
> > If you did the second, then there is a special way in which your
> > Python code must create those instances so that they know that they
> > must export themselves with the xsi:type="xxx" attribute.
> >
> > I recently had a question about this same issue, again *if* it's the
> > second way of creating instances that we are talking about. If it
> > is, then you can either take a look at my answer to a question about
> > that issue here:
> > https://sourceforge.net/p/generateds/mailman/message/36433595/
> >
> > Or, better yet, I believe, look at this addition I made in response
> > to that question to the `generateDS` documentation in section "Types
> > derived by extension":
> > http://www.davekuhlman.org/generateDS.html#types-derived-by-extension
> >
> > Here is an attempt to reproduce what I *think* you are trying to do:
> >
> > I generated a module from `EsdlXML.xsd`:
> >
> > $ ./generateDS.py -o esdlxmllib.py EsdlXML.xsd
> >
> > Then I ran this Python code:
> >
> > # sample03.py
> > import sys
> > import esdlxmllib
> >
> > def test():
> > instance = esdlxmllib.Instance()
> > area = esdlxmllib.Area()
> > asset = esdlxmllib.WindTurbine()
> > asset.original_tagname_ = 'Asset'
> > asset.extensiontype_ = 'WindTurbine'
> > area.add_asset(asset)
> > instance.area = area
> > instance.export(sys.stdout, 0)
> >
> > test()
> >
> > And, it printed out this:
> >
> > $ python sample03.py
> > <esdl:Instance xmlns:esdl="http://www.tno.nl/esdl/180901";>
> > <esdl:area xmlns:esdl="http://www.tno.nl/esdl/180901";>
> > <esdl:Asset
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:type="WindTurbine"/>
> > </esdl:area>
> > </esdl:Instance>
> >
> > Is that what you are trying to get? I've attached the above sample
> > code (sampe03.py), in case it's helpful.
> >
> > If the above does not help you solve your problem, please give me a
> > little more information to work with, so that I can reproduce your
> > problem.
> >
> > Dave
> >
> >> On Sat, Oct 13, 2018 at 04:37:06PM +0000, Matthijssen, E.F. (Edwin) via
> >> generateds-users wrote:
> >> Hello,
> >>
> >> We've developed a model for energy systems using the Eclipse
> >> Modeling Framework and we're trying to use GenerateDS to create
> >> python classes. The project is hosted here:
> >> https://github.com/EnergyTransition/ESDL-Python
> >>
> >> A picture of the class diagram can be found here:
> >> https://github.com/EnergyTransition/ESDL/blob/master/esdl/model/esdl.png
> >>
> >> The Eclipse tooling allows exporting the model as an XML schema
> >> definition. There are two different options: - An xsd based on
> >> XML:
> >> https://github.com/EnergyTransition/ESDL-Python/blob/master/model/EsdlXML.xsd
> >> - An xsd based on XMI:
> >> https://github.com/EnergyTransition/ESDL-Python/blob/master/model/esdlXMI.xsd
> >>
> >> No matter what xsd we use as an input, we get undesired output
> >> when we try to write an instance of a EnergySystem to a file.
> >>
> >> The problem exists where we use a collection of an abstract class,
> >> with many sub classes. In the example below area is an instance of
> >> class Area. An Area can contain 0 to many (0..*) Assets. Asset is
> >> an abstract class and WindTurbine is a subclass of Asset.
> >>
> >> The desired output should look like this:
> >>
> >> <esdl:EnergySystem>
> >> <esdl:instance>
> >> <esdl:area>
> >> <esdl:asset xsi:type="esdl:WindTurbine">
> >> ...
> >> </esdl:asset>
> >> </esdl:area>
> >> </esdl:instance>
> >> </esdl:EnergySystem>
> >>
> >> Using the XML version of the XSD, the output looks like:
> >>
> >> <esdl:EnergySystem>
> >> <esdl:instance>
> >> <esdl:area>
> >> <esdl:WindTurbine>
> >> ...
> >> </esdl:WindTurbine>
> >> </esdl:area>
> >> </esdl:instance>
> >> </esdl:EnergySystem>
> >>
> >> Using the XMI version of the XSD, the output looks like:
> >>
> >> <esdl:EnergySystem>
> >> <esdl:instance>
> >> <esdl:area>
> >> <esdl:asset>
> >> ...
> >> </esdl:asset>
> >> </esdl:area>
> >> </esdl:instance>
> >> </esdl:EnergySystem>
> >>
> >> Any ideas how to get this right? Any help is highly appreciated
> >>
> >> Regards,
> >> Edwin
> >>
> >>
> >>
> >>
> >> This message may contain information that is not intended for you. If you
> >> are not the addressee or if this message was sent to you by mistake, you
> >> are requested to inform the sender and delete the message. TNO accepts no
> >> liability for the content of this e-mail, for the manner in which you use
> >> it and for damage of any kind resulting from the risks inherent to the
> >> electronic transmission of messages.
> >
> >
> >> _______________________________________________
> >> generateds-users mailing list
> >> generateds-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/generateds-users
> >
> >
> > --
> >
> > Dave Kuhlman
> > http://www.davekuhlman.org
> > <sample03.py>
--
Dave Kuhlman
http://www.davekuhlman.org
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
