Glen Mazza wrote: > --- 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.
First, that is not a use case. Second, nobody is trying to duplicate code. There is a bit of extra code for interfaces, but that is quite different than duplication. FOPException doesn't have to be duplicated, although that is one option. To do it right, it would have to be moved. I looked at the command-line code & the user doesn't need to know about FOPException at that level. I don't know what effect it might have on embedded stuff, but I *think* that could be handled fine as well. I don't know what you have going in AWTRenderer, so I can't comment on it. I was hoping that you would explain it in broad terms. I am afraid that whatever it is, is exactly the kind of stuff that I am trying to prevent by structuring the project into modules. > > 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. Since were talking about a computer program here, the cost of A bringing the ingredients to me and me taking them to B is exactly the same (or darn close) as the cost of A delivering it directly to B. The benefit is that I can (if I want to), send half of the ingredients to P and half to Q instead of sending all of them to B. Or I can have B send me a bit of the dough as it is made instead of waiting for the whole batch to be completed. Or I can move the ingredient-buying section of my warehouse to a different country or planet. > > > (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. I'm not in favor of duplicating anything, just trying to add a bit of discipline to a project that IMO can use some. The frustrating thing is that we lack moving just five classes to be able to deliver a totally independent FO Tree implementation. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
