No, I did nothing to XMLBeans, or the generated schemas to make this happen.
-----Original Message----- From: Dominik Stadler [mailto:dominik.stad...@gmx.at] Sent: Thursday, October 27, 2016 2:42 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: Functionality injection technique for XWPF 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/bf36bb08edb00d471b69bb70579a > 96 > 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
