poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Stadler <dominik.stad...@gmx.at>
Subject Re: Functionality injection technique for XWPF
Date Fri, 21 Oct 2016 19:10:50 GMT
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
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).


On Fri, Oct 21, 2016 at 1:17 PM, Murphy, Mark <murphymdev@metalexmfg.com>

> 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:apache@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-unsubscribe@poi.apache.org For additional
> commands, e-mail: dev-help@poi.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message