If it works, that's all that matters to me.
When and if we see a significant divergence in these 2 things:
1. How a FopFactory is gotten, along with possibly tons of attributes and config
2. How a FopFactory is used, along with possibly complex run-time parameters
then we talk about splitting the ApacheFopFactory and the Fop Worker.
I rest my case.
Jonathon
Adrian Crum wrote:
Okay, it's done:
https://issues.apache.org/jira/browse/OFBIZ-1414
Comments welcome.
-Adrian
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
