--- Victor Mote <[EMAIL PROTECTED]> wrote: > 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. >
I'm -1. The decision for changing FOP architecture is based on votes--not just by current but future committers, who may have other architectural ideas that don't include FOTree isolation. Enforcing architectural designs via the build process could be hindering future design issues from presenting themselves and being voted on. There are two major architectural paths for FOP--one is based on the pipeline approach (apps package just activates the FO processing which interfaces with Area Tree processing, etc., etc., with business logic split among the five areas), which I tended to favor, and the other is the controlling-class approach (have apps run the show, and render the other areas as primarily services to it), largely supported by you and the other committers. On the basis of all your work over the past several weeks in cleaning up the code, as well as the fact that the other committers either have little problem with or actually support the controlling-class approach, I have no problem with us going in this direction right now. I don't want to freeze out, however, a future pipelined approach should inordinate problems present themselves with this design. (Besides, my AWTRenderer is reentrant, and depends on a locally created Driver instance to reload its document! ;) > 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 > Arguably, you would need to add Version and XSLTInputHandler as well to this. But we have a more pressing concern with backwards compatibility (with FOPException and the embedded InputHandlers) and also user (embedded) code cleanliness--when users embed FOP in their code, I would rather they only access one of our packages (namely org.apache.fop.apps), rather than multiple packages--that wouldn't look like a good design decision on our part. fop.PDF.* I would like to have moved under the render.pdf package as a new subpackage--because everything within it is specific to PDF rendering, and none of the other renderers. Also, I would like to move the fop.viewer package to render.awt.viewer as well--again, it is only specific to AWT Rendering. FOUserAgent's location I don't care about. > 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). > Too early to tell, I think. You have 90% isolation, I think that's good enough right now--perhaps working on the old layout would be best at this time. Glen __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
