Peter B. West wrote:
> Regarding configuration in FOP, it is interesting to note that there are 
> two different config hierarchies depending on whether the environment is 
> uniform, as, e.g., in a single thread, or diverse, as in the example 
> Arnd offered.  (That is, a separate process constructs stylesheet 
> information and other variables into an instance-specific storage 
> location, and invokes a fop thread with a reference to that location.)
> In the first case, the config hierarchy is:
> system config
> user config
> command line

This is an application centric view. And these are the traditional
contexts used in many other application in order to avoid repeated
setting of almost static stuff while still allowing flexibility.

We are dealing with other points of view:
- FOP used embedded in some other software consuming and producing
   byte streams
- FOP as part of other software performing its own drawing and user
- FOP as a self contained application
You config hierarchy applies only to the last.

The first application of FOP should only make minimal assupmtions
about available infrastructure and other environmental issues. In
particular, it should not assume there are even config files or
command line parameters directly regarding FOP to read. There is
no use to distinguish between various config files and command line
parameters. The mechanisms used should be universally available,
like Java properties for very static stuff and fallback values
and interfaces for supplying user font data, for which there
could be a default implementation which reads the data from URLs,
which by default are resolved to certain file URLs.

Around this core could be a shell which provides for FOP specific
config files and command line parameter filtering, much like the
XWindows libraries provide similar stuff. This can be used both
for embedding FOP elsewhere as well as for a stand alone FOP

For the core, I'm still thinking the factory pattern used by JAXP
is sensible: the factory is a singleton which serves as a template
for the FO processors. All default configuration values are kept
there, they are initialized with fallback values hard coded or
read from java properties when the factory is created and can
be changed at any time. After a processor is created, the settings
for this processor can still be changed until the formatting run
starts. After the run ends, the processor object is discarded (no
reset) and new processors are obtained from the factory. There
are no MT issues because all methods on the factory and the
processor object are synchronized at their respective objects,
and the objects hold all necessary data. This model suits the
servlet environment particularly well. It could be claimed that
some stuff from a processor run could be reused and should be
cached, for example the FO tree. But I think you can as well
cache the produced byte stream. It's another matter in case
of the AWT renderer, there could be possibly many rerenderings
form the same area tree (console refreshs, scrolling etc). But
then, the AWT rendering processor is no necessarily discarded
after each display refresh.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to