Nice!
I would recommend keeping ApacheFopFactory, and then creating ApacheFopWorker to use
ApacheFopFactory. Keep the 2 de-coupled; we never know when we gotta extend ApacheFopFactory.
> If the FOP API changes, only the ApacheFopWorker would have to be updated.
Oh, you're so right. I did some work for an Opentaps client who blindly updated his Opentaps
installation with both Opentaps and OFBiz recent updates. Yup, wrong medication and complications
all over the place (hence my recent post with "OFBiz updates as medication" metaphor).
One sticky issue was the old FOP in his Opentaps. His PDFs weren't showing up correctly (or was it
just barcodes?). I had a difficult time upgrading his codes to support a newer FOP.
Your ApacheFopWorker will save us a lot of trouble as OFBiz grows together with
FOP.
Jonathon
Adrian Crum wrote:
Currently, the ApacheFopFactory class does nothing more than return a
FopFactory class instance. Looking through the project, I see a lot of
redundant code to render documents via FOP. I'd like to refactor the
ApacheFopFactory to include some helper methods that would eliminate
much of the redundant code.
Here is what I have in mind:
1. Rename ApacheFopFactory to something like ApacheFopWorker, OR create
a new class that references ApacheFopFactory.
2. Move a lot of the stream preparation and rendering code to
ApacheFopWorker.
3. Update existing OFBiz code to use the new class.
There are two things I can see being accomplished:
1. Code reduction.
2. Decouple FOP code from the multitude of classes that currently use
it. If OFBiz code only called ApacheFopWorker class methods, then the
code base would be shielded from FOP API changes. If the FOP API
changes, only the ApacheFopWorker would have to be updated.
It would be the same basic concept as the current FreeMarkerWorker class.
What do you think?
-Adrian
