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]
