Hi, This looks very promising on the usages side, is there anything needed on the XmlBeans code-generation side?
Thanks... Dominik. On Tue, Oct 25, 2016 at 10:48 PM, Mark Murphy <jmarkmur...@gmail.com> wrote: > 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/bf36bb08edb00d471b69bb70579a96 > 2c22039bac > > On Tue, Oct 25, 2016 at 7:34 AM, Murphy, Mark <murphym...@metalexmfg.com> > 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: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 > > > > >
