I have an even better solution now. It involves using the XmlBeans cursor to insert bits into the structure. I have a working prototype that I will post to GitHub tonight when I get home. This is very promising, particularly as it seems to be the way that issue #56854 alludes to as being the best way to update the XML vs. Lists and Arrays. It also should provide a way to reorder XML which was the cause of an issue I came across in XLSX earlier. An issue with shift rows leaving rows out of order in the spreadsheet #59581 and #57423. The beauty of this solution is that we don't have to monkey with the generated interfaces. XMLBeans gives us a way to accomplish our goal in a schema agnostic way.
-----Original Message----- From: Mark Murphy [mailto:jmarkmur...@gmail.com] Sent: Saturday, October 22, 2016 6:37 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: Functionality injection technique for XWPF 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
