Thanks for showing bits, that makes it easier to start a discussion! So what you are trying to handle are different CT_... classes which have very similar content and thus would require repeated code otherwise.
I see the following options in general for handling something like that: 1. Reflection to access similar classes in one way 2. Generate a small additional layer of code that encapsulates this duplication 3. Use XmlBeans to "Weave-in" some additional interfaces into the CT_... classes to handle this 4. Use a separate 3rd party functionality to "weave-in" or add aspects. Personally I would prefer 2. over 1. because it keeps the code easier to debug. You could maybe even automatically detect similar things automatically and create the code accordingly. Idea number 4 would add a complex dependency that likely has it's own set of problems, for 3. I am not sure if feasible, could be nice if XmlBeans supports it Another point to consider is that reflection can have quite a performance penalty, so as soon as it is involved in calls that are done a lot, you will be limited pretty soon when handling larger documents (I am not sure what use an Excel file with 1 mio rows or a Word document with thousands of pages is, but somehow our users want to do it all the time). Dominik. On Fri, Oct 21, 2016 at 1:17 PM, Murphy, Mark <murphym...@metalexmfg.com> wrote: > Take a look at this commit, it shows what I am talking about. There is > still a lot more to do, but I don't want to go too far down a path that > will be incorrect. The classes XMLContent and XMLMarkup are delegates that > provide common functionality to XWPFDocument, and XWPFHeaderFooter, > XWPFTableCell, XWPFComment, XWPFFootnotes, etc. There is still a little > overlap between XWPFDocument and XMLContent since I haven't fully added all > the necessary parts to XMLContent yet, but eventually, the paragraphs, > tables, and bodyElements properties in XWPFDocuments would be migrated > fully to XMLContent, and the only methods implemented in XWPFDocument would > be code that is specific to the Document part, for example Section code, > though I think that might end up with its own class as well. > > I have run this through the unit tests, and there are some bugs in it > which I am in the process of correcting locally, but this gives a decent > overview of what I am thinking of. Once this is complete, we would be able > to fix bugs in paragraph, or Table code in a single location. > > I still am unsure about what to do with the Exceptions that this throws. I > think they should be handled as close to the source as possible, but what > logging exists to handle this, and how would you notify the user that an > issue exists. > > Here is a link to the commit in my GitHub repository. > > https://github.com/apache/poi/commit/3bc9cf77fd690132257f9524ebc95d > b3ec7bde03 > > -----Original Message----- > From: Nick Burch [mailto:apa...@gagravarr.org] > Sent: Monday, October 17, 2016 2:51 AM > To: POI Developers List <dev@poi.apache.org> > Subject: Re: Functionality injection technique for XWPF > > On Mon, 17 Oct 2016, Mark Murphy wrote: > > I found I should be able to do it using reflection to avoid long > > strings of instanceof conditions which is really the same as > > duplicating the code, but all inside one class. Any issue with using > Reflection? > > If you post some of the code you're working on, with some ideas, we can > hopefully all take a look and see if we can help improve things > > Feel free to post to a github gist, a branch on your own github, a branch > in svn, patch to jira etc! > > (Quite a bit of XWPF has come from user contributions, so may well be > missing some overall architecture improvements that piece-meal fixes didn't > require) > > Nick > > --------------------------------------------------------------------- > 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 > >
