FOP Developers:

The FO Tree isolation work is complete, with the exception of a few classes
that I would like to move around, and for which I would welcome input. I
started this for the purpose of making sure that layout and FO Tree were
isolated, but I actually ended up isolating FO Tree from everything else. I
think this not only has benefits in helping us keep our code modularized,
but also has potential to make the FO Tree be useful to other projects as a
separate stand-alone product. In other words, we could think of FO Tree as a
separate project that is a service to FOP and to anyone else who might
benefit from such a data structure.

As I proceeded with this work, it seemed to me that there are a total of
five such modules within FOP. The table below summarizes these modules, with
column 1 representing the FO Tree, column 2 the area tree, column 3a the
renderers, column 3b the layout, and column 4 the FOP application itself. Of
these five isolation groups, only column 1 is realized currently.

Package    1   2   3a  3b  4
---------|---|---|---|---|---|
apps     |   |   |   |   | x |
area     |   | x |   |   |   |
datatypes| x |   |   |   |   |
fo       | x |   |   |   |   |
fonts    | x |   |   |   |   |
image    | x |   |   |   |   |
layout   |   |   |   | x |   |
layoutmgr|   |   |   | x |   |
mif      |   |   | x |   |   |
pdf      |   |   | x |   |   |
render   |   |   | x |   |   |
rtf      |   |   | x |   |   |
servlet  |   |   |   |   | x |
svg      |   |   | x |   |   |
tools    |   |   | x |   |   |
traits   | x |   |   |   |   |
util     | x |   |   |   |   |
viewer   |   |   | x |   |   |
---------|---|---|---|---|---|
common?  | x |   |   |   |   |

Columns 3a and 3b are at the same level because they could be done in either
order, and need to maintain isolation between themselves. So, in other
words, FO Tree should be built in isolation from everything else. Area tree
is built in isolation from everything except FO Tree. Renderers are built in
isolation from everything except FO Tree and Area Tree. Layout is built in
isolation from everything except FO Tree and Area Tree. Finally, the apps
pull all of it together.

Note 1: layout has further issues in that each layout strategy should be
built independently of all others, but of course with visibility of any code
that is designated as common to all of them.

Note 2: One could break column 1 into two columns, one for "common" code and
one for actual FO Tree building, but I don't see a great benefit to doing
so.

Now, I would like to change our build process to enforce the above
dependencies as they are realized. In other words, I would like to use our
build to help us make sure that we don't have code creeping between the
modules. Consider the five modules: apps uses everything, so all it needs to
do is build last. FO Tree and Area Tree are essentially data structures,
with methods to build and manage those structures. That leaves Layout and
Rendering, *both* of which now we are trying to make pluggable, and which
can and should be totally separate from each other. So I propose first that
keeping these five modules separate is a desirable thing, and should be
enforced by our build process (I'll write the code).

Here is my +1.

Now in the table above, the "common" package does not exist, but represents
five classes that I would like to move to complete the process of isolating
column 1. Those classes are:
  apps/FOPException
  apps/FOUserAgent
  apps/FOFileHandler
  apps/InputHandler
  pdf/PDFEncryptionParams

apps/FOFileHandler and apps/InputHandler could logically go into the FO Tree
package. The remaining items (or all of them) could go into util. They
basically represent things that are common to all FOP modules. I also
thought about creating a new exception class just for FO Tree building,
which would solve the isolation problem for column 1, but not for any other
modules. apps/FOUserAgent and pdf/PDFEncryptionParams are essentially
configuration classes. Does anyone care where I put them or object to me
moving them?

If we come to general agreement that subdiving FOP this way is good, I'll
complete implementation of it before trying to bring the old layout over
(which I am really itching to get started on).

Victor Mote


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

Reply via email to