I was looking at the WML schema, we could use the groups (EG_) to define interfaces. These are contained in other groups, and also in complex types (CT_). We could use that to build an inheritance structure of interfaces where an EG_ contains another EG_, and also an interface structure for the CT_ classes that contain EG_. There is only one EG_ that contains more than one other EG_ which would break inheritance. The second EG_ is a grouping for math objects which could be dropped from the inheritance and created as an independent interface which would be included for anything that implements the associated interface or its children.
This would likely require another generator to be run after the XMLBeans compiler, and it would have to be able to process the generated XMLBeans sources as well as the schemas. On Sat, Oct 22, 2016 at 8:41 AM, Andreas Beeker <kiwiwi...@apache.org> wrote: > > 3. Use XmlBeans to "Weave-in" some additional interfaces into the CT_... > > classes to handle this > Most of the time, I thought about this, I didn't want constant changes in > the schema jar. > But now we have a common type loader, and we could put a bit extra magic > in: > > Not sure if this works, but the POIXMLTypeLoader provides the classloader > to the xmlbeans > schema type loader. We could extend the xmlbeans implementation classes > and inherit > from a common interface. If the classloader determines there's a custom > implementation > class, e.g. by some package/classname convention, it could instantiate > this instead of > the original class. The problem is, the original class has to be > instantiated too, so I don't > know how that recursion would be handled sanely yet without checking the > caller stack ... > > If you think about how it would be done with Jaxb ... you probably would > add the interfaces > to the generation config and create a new schema jar. I think this should > be not too > difficult with xmlbeans too ... (and we had already a discussion about > that ... but I can't find it :( )... > So if you don't mind having more often updated schema jars, I would prefer > this way. > > Andi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
