RE: Functionality injection technique for XWPF

[Murphy, Mark]

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

Re: Functionality injection technique for XWPF

[Dominik Stadler]

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
> >
> >
>

Re: Functionality injection technique for XWPF

[Mark Murphy]

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 <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
>
>

RE: Functionality injection technique for XWPF

[Murphy, Mark]

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

Re: Functionality injection technique for XWPF

[Mark Murphy]

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 
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
>
>

Re: Functionality injection technique for XWPF

[Andreas Beeker]

> 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

Re: Functionality injection technique for XWPF

[Dominik Stadler]

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
>
>

RE: Functionality injection technique for XWPF

[Murphy, Mark]

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/3bc9cf77fd690132257f9524ebc95db3ec7bde03

-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

Re: Functionality injection technique for XWPF

[Nick Burch]

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

Re: Functionality injection technique for XWPF

[Javen O'Neal]

I would recommend against reflection no matter what the code savings are.

On Oct 16, 2016 9:18 PM, "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?
>
> On Sat, Oct 15, 2016 at 8:04 PM, Mark Murphy 
> wrote:
>
> > In working through the XWPF API I see a lot of notation concerning
> > duplicated code. This is because there are a lot of places which need the
> > same functionality, but they are not related in a way that can easily be
> > sub-classed. For example a Document Body can contain Comments, Paragraphs
> > and Tables. So can Headers, Footers, Footnotes, and Table Cells. In
> > addition, Tables can contain Comments, but not Paragraphs or other
> Tables.
> > Same for Table Rows. The content functionality can be sub-classed by
> > itself, but  many of the objects that need to use that functionality
> > already have a place in the class structure, and cannot extend another
> > class. So I need another way to inject that functionality. I have an
> idea,
> > but would like some validation from others who are more versed in Java
> than
> > I, so here is the thought.
> >
> > I would create two base content classes: Markup which would contain the
> > implementation for comments, bookmarks, custom XML, and a few other
> things
> > which are used universally throughout the various content parts; and
> > Content which would extend Markup and add Paragraphs and Tables, and
> > anything else that is used exclusively where paragraphs and tables can be
> > added. Both of these would have associated interfaces which would be
> > implemented in the parts that need this functionality. The part I am not
> > totally certain about is injecting this functionality into XWPFDocument,
> > XWPFTable, XWPFTableCell, XWPFHeaderFooter, etc. My thought is to have
> each
> > of these objects implement one of the two base content interfaces, and
> > contain a reference to its associated implementation class. Then to
> > complete the implementation, it would forward requests associated with
> > these interfaces to the implementation class.
> >
> > So XWPFDocument would include something like this:
> >
> > XWPFDocument extends POIXMLDocument implements IContent
> >
> > ...
> > private Content _content;
> > ...
> >
> > public XWPFParagraph createParagraph() {
> >   return _content.createParagraph();
> > }
> > ...
> >
> > I know there are other things I would need to do because the XWPFDocument
> > class keeps a list of paragraphs and tables, and I would have to update
> > those lists, but this is the gist of how I would remove the duplication
> of
> > implementation details from all the places where it currently exists. A
> lot
> > of objects can create paragraphs and tables, and even more can create
> > comment and bookmark artifacts.
> >
> > What do you think? Workable? Any cons to this approach?
> >
>

Re: Functionality injection technique for XWPF

[Mark Murphy]

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?

On Sat, Oct 15, 2016 at 8:04 PM, Mark Murphy  wrote:

> In working through the XWPF API I see a lot of notation concerning
> duplicated code. This is because there are a lot of places which need the
> same functionality, but they are not related in a way that can easily be
> sub-classed. For example a Document Body can contain Comments, Paragraphs
> and Tables. So can Headers, Footers, Footnotes, and Table Cells. In
> addition, Tables can contain Comments, but not Paragraphs or other Tables.
> Same for Table Rows. The content functionality can be sub-classed by
> itself, but  many of the objects that need to use that functionality
> already have a place in the class structure, and cannot extend another
> class. So I need another way to inject that functionality. I have an idea,
> but would like some validation from others who are more versed in Java than
> I, so here is the thought.
>
> I would create two base content classes: Markup which would contain the
> implementation for comments, bookmarks, custom XML, and a few other things
> which are used universally throughout the various content parts; and
> Content which would extend Markup and add Paragraphs and Tables, and
> anything else that is used exclusively where paragraphs and tables can be
> added. Both of these would have associated interfaces which would be
> implemented in the parts that need this functionality. The part I am not
> totally certain about is injecting this functionality into XWPFDocument,
> XWPFTable, XWPFTableCell, XWPFHeaderFooter, etc. My thought is to have each
> of these objects implement one of the two base content interfaces, and
> contain a reference to its associated implementation class. Then to
> complete the implementation, it would forward requests associated with
> these interfaces to the implementation class.
>
> So XWPFDocument would include something like this:
>
> XWPFDocument extends POIXMLDocument implements IContent
>
> ...
> private Content _content;
> ...
>
> public XWPFParagraph createParagraph() {
>   return _content.createParagraph();
> }
> ...
>
> I know there are other things I would need to do because the XWPFDocument
> class keeps a list of paragraphs and tables, and I would have to update
> those lists, but this is the gist of how I would remove the duplication of
> implementation details from all the places where it currently exists. A lot
> of objects can create paragraphs and tables, and even more can create
> comment and bookmark artifacts.
>
> What do you think? Workable? Any cons to this approach?
>

Functionality injection technique for XWPF

[Mark Murphy]

In working through the XWPF API I see a lot of notation concerning
duplicated code. This is because there are a lot of places which need the
same functionality, but they are not related in a way that can easily be
sub-classed. For example a Document Body can contain Comments, Paragraphs
and Tables. So can Headers, Footers, Footnotes, and Table Cells. In
addition, Tables can contain Comments, but not Paragraphs or other Tables.
Same for Table Rows. The content functionality can be sub-classed by
itself, but  many of the objects that need to use that functionality
already have a place in the class structure, and cannot extend another
class. So I need another way to inject that functionality. I have an idea,
but would like some validation from others who are more versed in Java than
I, so here is the thought.

I would create two base content classes: Markup which would contain the
implementation for comments, bookmarks, custom XML, and a few other things
which are used universally throughout the various content parts; and
Content which would extend Markup and add Paragraphs and Tables, and
anything else that is used exclusively where paragraphs and tables can be
added. Both of these would have associated interfaces which would be
implemented in the parts that need this functionality. The part I am not
totally certain about is injecting this functionality into XWPFDocument,
XWPFTable, XWPFTableCell, XWPFHeaderFooter, etc. My thought is to have each
of these objects implement one of the two base content interfaces, and
contain a reference to its associated implementation class. Then to
complete the implementation, it would forward requests associated with
these interfaces to the implementation class.

So XWPFDocument would include something like this:

XWPFDocument extends POIXMLDocument implements IContent

...
private Content _content;
...

public XWPFParagraph createParagraph() {
  return _content.createParagraph();
}
...

I know there are other things I would need to do because the XWPFDocument
class keeps a list of paragraphs and tables, and I would have to update
those lists, but this is the gist of how I would remove the duplication of
implementation details from all the places where it currently exists. A lot
of objects can create paragraphs and tables, and even more can create
comment and bookmark artifacts.

What do you think? Workable? Any cons to this approach?