You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@poi.apache.org by Nick Burch <ap...@gagravarr.org> on 2013/11/12 00:07:33 UTC
Re: Why OPCPackage cannot be extend?
On Wed, 30 Oct 2013, Angelo zerr wrote:
> So I have tried to extends OPCPackage by creating MyZipPackage (like you
> have done with your ZipPackage). But I cannot do that because of this code:
>
> -----------------------------------------------------
>
> OPCPackage(PackageAccess access) {
> if (getClass() != ZipPackage.class) {
> throw new IllegalArgumentException("PackageBase may not be subclassed");
> }
> init();
> this.packageAccess = access;
> }
The OPC code all came from the OpenXML4J project, which merged into Apache
POI a few years ago.
When we came to start adding OpenXML support to POI, we depended on then
later collaborated with the OpenXML4J project for the low level OPC
support. At some point after that, the OpenXML4J project decided to join
with POI, and that code came over
For the specific answer on why that restriction is there, I can't answer,
as it's based on a decision made before the code came to POI. My hunch is
that there are some deep baked assumptions in other parts of the OPC code
which could be broken if things weren't backed by a ZipPackage
Given that, there might well be a way we could allow you to pass in your
already open zip file, without breaking the assumptions elsewhere in the
code. Could you clarify what kind of object(s) you already have open?
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org
Re: Why OPCPackage cannot be extend?
Posted by Nick Burch <ap...@gagravarr.org>.
On Tue, 12 Nov 2013, Angelo zerr wrote:
> In short answer, I would like to use our XDocReport
> XDocArchive<https://code.google.com/p/xdocreport/source/browse/core/fr.opensagres.xdocreport.core/src/main/java/fr/opensagres/xdocreport/core/io/XDocArchive.java>
Our ZipEntrySource looks quite close to what your XDocArchive supports.
Would a constructor that took a ZipEntrySource work for you? (That would
avoid making changes to the rest of the OPC code, which is probably the
safest option!)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org
Re: Why OPCPackage cannot be extend?
Posted by Angelo zerr <an...@gmail.com>.
Hi Nick,
Many thank's for your answer.
>Given that, there might well be a way we could allow you to pass in your
already open zip file, without breaking the assumptions elsewhere in the
code. Could you clarify what kind of object(s) you already have open?
In short answer, I would like to use our XDocReport
XDocArchive<https://code.google.com/p/xdocreport/source/browse/core/fr.opensagres.xdocreport.core/src/main/java/fr/opensagres/xdocreport/core/io/XDocArchive.java>
Why?
XDocReport gives you the capability to create a docx "template" by using
mergefield (you use Freemarker/Velocity syntax) and merge it with Java
context to generate a docx report.
You can convert too the generated report to pdf or html with several
implementation of converter. We have developped our own docx-pdf,
docx->xhtml converter based on POI + iText
https://code.google.com/p/xdocreport/wiki/XWPFConverterPDFViaIText
Today here the steps :
1) load the "docx template" in a XDocArchive the docx
2) create a new XDocArchive which is the generated docx report.
3) create a byte array of the XDocArchive
4) load XWPFDocument from the byte array
5) generate iText from the XWPFDocument structures.
To improve performance and memory, I would like to avoid 3) steps and uses
my custom OPCPackage.
As it's not possible today, I have created a new converter which uses only
the OpenXML4J structures, but if we could use our own OPCPackage it should
be very cool.
Regards Angelo
2013/11/12 Nick Burch <ap...@gagravarr.org>
> On Wed, 30 Oct 2013, Angelo zerr wrote:
>
>> So I have tried to extends OPCPackage by creating MyZipPackage (like you
>> have done with your ZipPackage). But I cannot do that because of this
>> code:
>>
>> -----------------------------------------------------
>>
>> OPCPackage(PackageAccess access) {
>> if (getClass() != ZipPackage.class) {
>> throw new IllegalArgumentException("PackageBase may not be
>> subclassed");
>> }
>> init();
>> this.packageAccess = access;
>> }
>>
>
> The OPC code all came from the OpenXML4J project, which merged into Apache
> POI a few years ago.
>
> When we came to start adding OpenXML support to POI, we depended on then
> later collaborated with the OpenXML4J project for the low level OPC
> support. At some point after that, the OpenXML4J project decided to join
> with POI, and that code came over
>
> For the specific answer on why that restriction is there, I can't answer,
> as it's based on a decision made before the code came to POI. My hunch is
> that there are some deep baked assumptions in other parts of the OPC code
> which could be broken if things weren't backed by a ZipPackage
>
> Given that, there might well be a way we could allow you to pass in your
> already open zip file, without breaking the assumptions elsewhere in the
> code. Could you clarify what kind of object(s) you already have open?
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
> For additional commands, e-mail: user-help@poi.apache.org
>
>