Check this commit out on github, I created a way to generically create a paragraph in a common class and attach it to the delegator. This should allow me to consolidate common code into a few classes for XWPF without having to change our generated schema or resorting to reflection. https://github.com/JMarkMurphy/poi/commit/bf36bb08edb00d471b69bb70579a962c22039bac
On Tue, Oct 25, 2016 at 7:34 AM, Murphy, Mark <[email protected]> wrote: > 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:[email protected]] > Sent: Saturday, October 22, 2016 6:37 PM > To: POI Developers List <[email protected]> > 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 <[email protected]> > 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: [email protected] For additional > > commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
