RE: Functionality injection technique for XWPF
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 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 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 > > 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 > > 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 > > > > 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
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 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 > 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 > > 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 > > 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
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 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 > 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 > 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
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 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 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
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
> 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
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 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 > 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
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 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
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
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
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
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?