--- Victor Mote <[EMAIL PROTECTED]> wrote: > 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.
Well, when taken to 100%, the duplication of classes (FOPException) and functionality (Driver replacement in AWTRenderer) in order to pretend of an isolation that doesn't really exist to *that* extent. > 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. We have a different conceptual idea of a pipeline. To get my idea of it, imagine FOP being a bread bakery and you being the manager: The controller-class approach: 1.) You order an employee, say "A", to buy the flour/yeast. 2.) "A" gives you the flour/yeast. 3.) Next, you give the flour/yeast to another employee, "B", to make the bread dough. 4.) "B" returns to you with a big gob of bread dough. 5.) Next, you give the gob of bread dough to another employee, "C", to bake the bread. 6.) "C" returns to you with a tray of baked bread. 7.) Next, you give the tray of baked bread to a wrapping clerk, "D", to place the bread in a plastic bag. 8.) "D" returns to you with bagged bread. 9.) Next, you give the bagged bread to a customer. The pipeline approach: 1.) You order "Start working!" to employee "A". 2.) "A" buys the flour/yeast and gives it to "B" 3.) "B" makes the gob of bread dough and gives it to "C" 4.) "C" bakes the bread, and gives it to "D" for bagging. 5.) "D" bags the bread, and gives it to the customer. You are correct in that with the controller approach, employees A, B, C, D don't have to know each other. But some architectures might consider that type of interaction to be beneficial. Relations in controller-class approach: manager<-->A, manager<-->B, manager<-->C, manager<-->D, manager<-->customer In pipeline approach (theoretical, may not work in FOP's case): manager<-->A<-->B<-->C<-->D<-->customer Both appear valid. I'm not recommending we change our code, it's just that this is something that may be adopted to some extent in the future. > > (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. > > 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. But we may be losing sight of the forest for its trees--we already have a very clean Driver implementation in AWTRenderer (if you can offer improvements though that would be fine), and a very good FOPException working application-wide as well as in user embedded code. We're done at 90% isolation--no reason to duplicate stuff. 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]
