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").
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.
- "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
