Glen Mazza wrote: > --- 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.
Nothing I am proposing here should be construed to prevent future committers from changing this if they wish to. They can change the build process just as easily as we can. The point of having the build process enforce this is to at least make someone stop and think about it before doing so. Before starting down this path, I tried pretty hard to think of a use case where it is beneficial *not* to have the FO Tree isolated, and could not think of one. If you know of one, it will help a lot for you to mention it. It was a fair chunk of work to get it isolated, and I would like to make sure that it stays isolated unless there is a really good reason for it. > 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. I guess I don't see these as being so different, nor the distinction between them as the main issue. Even in a pipeline approach, the pipeline itself is defined somewhere. If we use Cocoon as an example (I am no expert, but think I grasp the concepts), the Cocoon script is the "glue" that binds the services together into a cohesive, useful pipeline. I view apps as being the place where that pipeline is defined. I frankly see a clear delineation of the tasks (i.e. getting & keeping the modules separate) as being a prerequisite for either approach, so I am more than a little confused by your objection. The main issue is whether we are modular or not. With two data structures and two processing concepts (both of which benefit from being pluggable), modularity (and distinction between modules) seems to me to be a high priority, around which we should work almost everything. Pressing the Cocoon analogy a bit further, if you had an XSLT processor that automatically fired up FOP each time it ran, it wouldn't be useful for anything other than running FOP. You couldn't use it, for example, to spit out HTML. So the fact that the XSLT processor is completely distinct from FOP (i.e. isolated) is a Good Thing. The build processes of the two keep them distinct, as it should be. Getting them mixed together would actually hinder the usefulness of the pipeline approach. > 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! ;) I'd be glad to help you think through how this could work differently. I still have a lot of cleaning up to do between Driver and Document, and I'll bet that anything you are trying to do can be handled properly when we get those classes cleaned up. > > 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. Those are good points. I guess I don't understand why anyone would need access to the InputHandlers? WRT FOPException, I can handle that by creating a new Exception class just for FO Tree, but then would have to do so for each of the other modules as well. That may be a good thing. I'll have to think about that some more. > 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. I agree that there is some more package moving that would be helpful. I really hate doing it because we can end up churning. > 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. Well, it won't take long for the 90% to go to 25% if we don't protect it. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
