Thanks Dave,
One update. I have changed my workaround to append some code to the
bottom of the generated file to create subclasses for all my named
elements. I think this will work for me;
for name, base_class in GDSClassesMapping.items():
def custom_init(self, *args, **kwargs):
super(self.__class__, self).__init__(*args, **kwargs)
self.original_tagname_ = self.__class__.__name__
type(name, (base_class,), {'__init__': custom_init})
I need this rather than just changing it on export since some of the
more complex structures were nesting the classes I want to rename and
I thus lost control of being able to call my custom export_mapped
function all the way down (I originally had a problem with recursive
inheritance when trying to do that and am somewhat too time
constrained for my first instance implementation to work around that
issue).
I quite like this new approach and figured it might be helpful.
Regards,
Philip
On 17 January 2017 at 11:11, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote:
> Philip,
>
> Sounds like an interesting problem and challenge. Give me a little
> time to think about it.
>
> Dave
>
> On Mon, Jan 16, 2017 at 12:41:27AM +1100, Philip Haynes wrote:
>> Hello,
>>
>> I am investigating using generateDS to write a FIXML (the XML version
>> of the FIX protocol). So far, very good results in parsing sample XML
>> and generating a comprehensive python binding to the API. However I
>> have a slight wrinkle. Perhaps I am using things incorrectly, but...
>>
>> The FIXML xsd is quite extensive (>26000 lines spread over 43 xsd
>> files) however inside the meat of the XML, there is a schema;
>>
>> <xs:schema targetNamespace="http://www.fixprotocol.org/FIXML-5-0";
>> xmlns:xs="http://www.w3.org/2001/XMLSchema";
>> xmlns="http://www.fixprotocol.org/FIXML-5-0";
>> xmlns:fm="http://www.fixprotocol.org/FIXML-5-0/METADATA";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://www.fixprotocol.org/FIXML-5-0/METADATA
>> fixml-metadata-5-0.xsd"
>> elementFormDefault="qualified" attributeFormDefault="unqualified">
>>
>> <xs:include schemaLocation="fixml-fields-impl-5-0.xsd"/>
>> ...
>>
>> and then various SimpleType, ComplexTypes and elements. It is the
>> elements I care about, for example;
>>
>> <xs:element name="UserReq" type="UserRequest_message_t"
>> substitutionGroup="Message" final="#all"/>
>> ....
>> </xs:schema>
>>
>> Now gDS generates classes called UserRequest_message_t which I can
>> happily instantiate and fill and then export to produce
>>
>> <UserRequest_message_t UserReqID="12324" UserReqTyp="1" Username="me"
>> Password="pwd">
>> <Hdr SID="CCC" TID="CBB" SSub="CCCUSER" TSub="CBCB"/>
>> </UserRequest_message_t>
>>
>> However I "want" the tag for this document to read "UserReq" from the
>> name in the element, not the type. I cannot see a way to create my
>> "UserReq" element programatically.
>>
>> I know that one way to get my desired XML document, would be to set
>> the original_tagname_ attribute on the instance of the object, but I
>> don't really want to have to do that for every instance I create.
>> Another way would be to set the name_ parameter on calling export
>> (likewise inconvenient). The frustrating thing is that the
>> GDSClassMapping dictionary already does this correctly when parsing
>> incoming XML files (albeit in reverse). So I am suspicious that I am
>> missing something here.
>>
>> My current approach is to monkey patch the gDS generated module after
>> loading to add a "export_mapped" method to the Abstract_message_t
>> class that is the base class for the relevant elements in the XSD and
>> with that function just call "export(..., name_ = <a magical reverse
>> lookup on the GDSClassMapping dictionary from the exporting class to
>> the required tag>)" thus calling export with the name_ parameter set
>> correctly and all is good.
>>
>> I feel that this approach is an inelegant solution to something that
>> could well already be solved in gDS but I just can't work it out.
>>
>> I have scanned the archive of this mailing list and cannot find
>> anything that seems to be related to my "issue" and so I post on a new
>> thread.
>>
>> Thanks,
>> Philip
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> generateds-users mailing list
>> generateds-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/generateds-users
>
> --
>
> Dave Kuhlman
> http://www.davekuhlman.org
--
Philip Haynes
Director, Dayneson Pty Ltd ATF the Davidson Haynes Family Trust
Address: 33 Arthur Street. Dee Why. NSW. 2026. Australia
Email: phi...@dayneson.mine.nu
Mobile: +61411050016
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
