Dave, thanks for your efforts, I really appreciate it. Some comments & thoughts of mine to your suggestions below. It's mainly about naming, so none of it is essential to me. In general, what you suggested will work just fine. Did you also find an explanation what actually caused different rendering of the child elements?
I will start to dig through the code a bit more, so next time I can provide some patches ;) Best Regards Florian > -----Ursprüngliche Nachricht----- > Von: Dave Kuhlman [mailto:dkuhl...@davekuhlman.org] > Gesendet: Mittwoch, 26. April 2017 01:28 > An: Florian Wilmshoever > Cc: generateds-users > Betreff: Re: Cardinality of child elements > > Florian, > > OK, so you do need that option. I thought there might be a chance that I > could slither out of some work. > > But, you are right; those are separate tasks and they should be made to be > independent of each other and individually optional. > > Actually, it does not look that difficult (although I might discover a > "got-cha" > along the way). I believe I have most of the code in place. ... oops, wait, I > remembered another place where I need to add some code. And, of course > I need test it and make it work. > > But first, so that you can give me some advice in advance, here is what the > new change will do: > > There will be a new command line option: --preprocess-operations. > The value will be a space separated string containing a list of preprocessing > operations to be performed by process_includes.py. > The default value will be "" (which will be equivalent to "all"). Like this you will get two ways to achieve the same thing. My suggestion would be to just have one deactivation switch on the commandline, like --no-includes --no-anon-types-raise --no-groups This way there may be less misunderstanding, if the user actually needs to activate some these. > Possible operations will be: > > - "includes" -- Recursively process and insert (or accumulate) xs:include and > xs:import elements. > > - "fix-type-names" -- Replace type names as specified by command > line option --fix-type-names. > > - "anon-types" -- Raise anonymous complexType definitions to top > level and give them each a name. As this is default behavior at the moment, I would maybe consider to not make this changeable at all. From my point of view this can possible break a lot of functionality, when activated. On the other hand I don't really know about peoples' use cases here so maybe there is some valid scenario where you want to switch this off. > > - "groups" -- Process and replace group definitions. > > - "" or "all" -- Do all the above preprocessing operations. > > And, the old option --no-process-includes will turn them all off. > > For your need, I believe you will use the following value: > > --preprocess-operations="fix-type-names anon-types groups" > > which will mean: do everything *except* process xs:include and xs:import > elements. > > Does that give us what we need? And, if you have suggestions about this, > please send them along. > > Dave > > > On Tue, Apr 25, 2017 at 08:52:42AM +0000, Florian Wilmshoever wrote: > > Dave, > > well of course I need the option, otherwise I wouldn't have tried to > > use it ;) > > > > The amount of schemas I need to generate bindings for has increase > recently. > > The include-scheme is roughly structured like this: > > > > -schema_A included by schema_B > > -schema_A included by schema_C > > -schema_B included by schema_C > > > > The problem when not using --no-process-includes is that it will > > generate a lot of boilerplate code I don't really need in the > > respective module. This may add up to the point that I get type > > conflicts when importing the generated modules for schema_B and > schema_C. So it's really not advisable to do that as it may break the > depending application in the future. > > > > Can you elaborate a little on the reasons? Is there any design ratio > > behind anonymous name handling and validator bodies being linked to this? > > Would it be possible to separate those functions from the actual inclusions > of other schemas? > > Ideally I would just have a function which will not generate any > > classes/types from included schemas but otherwise behave exactly the > > same. That's at least what I was going for :) > > > > As a start it would be great, if we could work something out for the > > different behavior concerning the child elements. I'm currently > > struggling to get a proper hang on your code, but let me know if I can help > still. Maybe point to sections where that is actually happening or something. > > > > Regards > > Florian > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Dave Kuhlman [mailto:dkuhl...@davekuhlman.org] > > > Gesendet: Montag, 24. April 2017 23:06 > > > An: Florian Wilmshoever > > > Betreff: Re: Cardinality of child elements > > > > > > Florian, > > > > > > Is there some reason why you want or need the "--no-process-includes" > > > command line option? > > > > > > `process_includes.py` actually performs several other > > > "pre-processing" tasks in addition to pulling in the referenced xs:import > and xs:include documents. > > > That is a little misleading and these additional tasks are not > > > mentioned in the documentation. So, I have added a few notes, both > > > the help/usage message that you see in response to `generateDS.py > > > --help` and to the documentation `generateDS.txt` (and > > > `generateDS.html`). Here is that added > > > information: > > > > > > Do not process included XML Schema files. By default, > > > generateDS.py will insert content from files referenced by > > > ``<include ... />`` elements into the XML Schema to be processed. > > > See section `Include file processing`_. Note that include > > > processing, which is performed in ``process_includes.py`` is > > > required for generating validator bodies from the XML schema, > > > because the Lxml ElementTree produced in ``process_includes.py`` > > > is needed to generate the validator code. So, using this option > > > also turns off automatic generation of validator code. Also > > > note that process_includes(.py) performs additional tasks; it > > > also (1) assigns names to each anonymous complexType, (2) > > > processes (replaces) group definitions, and (3) possibly fixes > > > complexType names (see command line option --fix-type-names). > > > > > > I had to read through the source code in `process_includes.py` > > > myself in order to "remember" what these tasks were. > > > > > > At any rate, I don't believe that you want to use the "--no-process- > includes" > > > command line option unless you have a real need. > > > > > > Still, I've run generateDS.py on apitest.xsd and have attached the > > > results: > > > > > > - tmp01sup.py: Generated without --no-process-includes > > > > > > - tmp02sup.py: Generated with --no-process-includes > > > > > > And, after inspecting the generated code, it looks like you are > > > correct that `child1` and `child2` are treated differently depending > > > on whether the --no- process-includes" command line option is used. > > > > > > - Without that option, it is generated as a single. > > > > > > - With that option, it is generated as a list. > > > > > > So, the question is: When you run generateDS.py *without* the --no- > > > process-includes (which is what I believe you should be doing), do > > > you get the results that you want and that are usable for your purposes? > > > > > > Dave > > > > > > > > > On Mon, Apr 24, 2017 at 08:39:22AM +0000, Florian Wilmshoever wrote: > > > > Hi Dave, > > > > thanks for the quick reply. > > > > > > > > Schema file you attached seems fine to me. The important part is > > > > the cardinality of the first sequence. > > > > I was able to reproduce the api you send me. The key difference as > > > > I just figured out is the '--no-process-includes' option rather > > > > than the latest package version as it seems. > > > > I reran my test and got the same result as you in the key places > > > > for the child elements when omit that option on the commandline. > > > > Would be great, if you could try again with the > > > > no-process-includes option and see if you get the same results. > > > > I attached my results for reference. > > > > What's also a bit weird is that all generated class names for > > > > elements below root lose their 'Type'-suffix if you use the > > > > no-process-includes option. > > > > > > > > I mainly need to know if this is intended behavior. I don't mind > > > > the refactoring as long as I only need to do it once ;). > > > > If you need me to do it on 2.25a or something just let me know, I > > > > just figured from the changelog it shouldn't make much of a difference. > > > > > > > > Thanks in Advance & Best Regards > > > > Florian > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Dave Kuhlman [mailto:dkuhl...@davekuhlman.org] > > > > > Gesendet: Samstag, 22. April 2017 01:15 > > > > > An: Florian Wilmshoever > > > > > Betreff: Re: Cardinality of child elements > > > > > > > > > > Florian, > > > > > > > > > > Attached is that generated module that I mentioned. I've also > > > > > attached the apitest.xsd file I used, in case you have different > > > > > version of it and want to check that I used the one you intended. > > > > > > > > > > Let me know how I can be of more help. > > > > > > > > > > Dave > > > > > > > > > > > -- > > > > > > Dave Kuhlman > > > http://www.davekuhlman.org > > -- > > Dave Kuhlman > http://www.davekuhlman.org ------------------------------------------------------------------------------ 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
