RE: fo isolation complete (almost)
Glen Mazza wrote: > --- Victor Mote <[EMAIL PROTECTED]> wrote: > > > > If I'm going to give up encapsulation or Separation > > of Concerns, or whatever > > you want to call it, what do I get in return? > > > > IMO you're not "giving up" SoC, you're gaining it: > > The > "manager<-->A<-->B<-->C<-->D<-->customer model" > keeps the business logic inherent to each object's > duties within each object. > > The other model, in which the manager sticks his > fingers in various parts of the process in every > object, is what I consider to break encapsulation. We must be talking about two different things here. Does the Bourne shell "stick his fingers" into sed when I pipe from grep to sed to wc? In your model, grep has to know to pass to sed, which has to know to pass to wc. Single-purpose, can't be reused for anything else. Does Cocoon "stick his fingers" into Xalan when I use it to convert semantic XML to XSL-FO to PDF. No. In your model, Xalan is only usable in that context. Can't use it to convert to HTML. > > I give > > up reusability, > > Not necessarily--going back to the bakery example > (where reusability = hirability externally), Employee > A fully knows how to buy the bread, B knows how to > make the dough, C knows how to cook it, etc. They are > all very smart, self-contained objects. Nope. Reusability is = being able to hire them out to other entities. If A only knows to pass to B, then he can't be used to pass to anybody else. > In the other model, by taking business logic out of > the objects and into the manager the A, B, C, D become > more dependent on that specific manager, and less > hirable without him/her. Nope. No business logic gets transferred to the manager, except for higher level decisions, which belong there anyway. A doesn't get to decide whether he buys ingredients for bagels or cinnamon rolls, he just buys ingredients. If he is taught only to buy for bagels, he can't be used for cinnamon rolls. Some outside entity tells him what to do. He doesn't even need to know why. This is analagous to a shell script (in my Bourne shell analogy), or to a Cocoon script in the Cocoon analogy. Passing parameters to an application or a function does't mean you are sticking your fingers into its business. It means that you are telling it in general terms what it should operate on, not how it should operate. > > simplicity, > > and the ability to divide-and-conquer. > > For these two, indeed all of them, one can probably > argue either way. Let's agree to disagree. It is true that one can argue either way, but what is expected here is a *coherent* argument. If this is really just a matter of opinion, and the results don't matter, than you would surely have voted a +0 or a -0, instead of a -1. I'll admit I don't know everything, and perhaps you have some insight that I don't grasp. If so, I hope I am humble enought to learn. But I can't find anything to learn yet. WRT "let's agree to disagree", that might work well in a commercial environment where there is some higher authority that can resolve such issues. I think it is almost useless in Open Source. If you undo tomorrow or next year what I do today, we have both wasted a lot of time. So as time consuming and difficult as resolving stuff in this forum is sometimes, it is a lot more efficient than code thrashing. Assuming that we are both intelligent and reasonable, I can think of no good reason why we can't come to an agreement about design issues. I take no offense at the negative vote. But I want you to understand that I don't put proposals forth lightly. If there are aspects I don't see, please enlighten me. If my education is deficient, tell me, and I'll work on correcting it. Both are possible. However, I do take offense when proposals are disapproved with no coherent reason attached. That is either careless or disrespectful on your part. If you have a good reason for voting negatively, give it to us and defend it, but don't say "let's agree to disagree" and hide in the tall grass. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo isolation complete (almost)
--- Victor Mote <[EMAIL PROTECTED]> wrote: > > If I'm going to give up encapsulation or Separation > of Concerns, or whatever > you want to call it, what do I get in return? > IMO you're not "giving up" SoC, you're gaining it: The "manager<-->A<-->B<-->C<-->D<-->customer model" keeps the business logic inherent to each object's duties within each object. The other model, in which the manager sticks his fingers in various parts of the process in every object, is what I consider to break encapsulation. > I give > up reusability, Not necessarily--going back to the bakery example (where reusability = hirability externally), Employee A fully knows how to buy the bread, B knows how to make the dough, C knows how to cook it, etc. They are all very smart, self-contained objects. In the other model, by taking business logic out of the objects and into the manager the A, B, C, D become more dependent on that specific manager, and less hirable without him/her. > simplicity, > and the ability to divide-and-conquer. For these two, indeed all of them, one can probably argue either way. Let's agree to disagree. 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]
RE: fo isolation complete (almost)
Glen Mazza wrote: > Not to belabor the point, but all of the above is > business logic, which can be supported by either > model. A computer program is deterministic--that > coded decision to send half to P and half to Q > (instead of B) based on various coded circumstances > can be placed within the manager or within A. If I'm going to give up encapsulation or Separation of Concerns, or whatever you want to call it, what do I get in return? I give up reusability, simplicity, and the ability to divide-and-conquer. What benefit can you show for this cost? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo isolation complete (almost)
--- Victor Mote <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > 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. > Not to belabor the point, but all of the above is business logic, which can be supported by either model. A computer program is deterministic--that coded decision to send half to P and half to Q (instead of B) based on various coded circumstances can be placed within the manager or within A. 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]
RE: fo isolation complete (almost)
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]
Place committers on inactive list? (RE: fo isolation complete (almost))
--- Victor Mote <[EMAIL PROTECTED]> wrote: > > Conclusion: We have three active committers right > now, one positive, one > negative, one lukewarm, so I will abandon the > enforcement idea. > > Victor Mote > I don't see anyone modifying the new Apps/FO code anyway--for backwards compatibility, apps will need to remain pretty much as you've molded it for 1.0 anyway. Thanks for all your hard work. As for the "three active committers" (five, with Christian and Jeremias!) point though, should we start retiring some of our long-inactive committers to the inactive list? They can always still commit code (and immediately make themselves active again in the process), but just can't vote. Keeping our active contributor/committer list really "active" may help attract more contributors and future committers. Perhaps Karen, Arved and Bertrand should be added to the inactive list. Two of our contributors, Anton Tagunov and George Yi, I have not heard from since joining FOP, although I may have missed their names. Comments--especially from those listed above--most welcome. 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]
RE: fo isolation complete (almost)
--- 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]
RE: fo isolation complete (almost)
J.Pietschmann wrote: > Victor Mote wrote: > [interesting stuff] > > Package1 2 3a 3b 4 > > tools| | | x | | | > Should be 4 (apps) module, I think. > > > util | x | | | | | > Uh, I never liked that. > > > Here is my +1. > +0 > > > 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 > +1 > > apps/FOUserAgent > ??? AFAIK, this is really configuration options. > > apps/FOFileHandler > > apps/InputHandler > Should stay in apps See below for discussion. > > pdf/PDFEncryptionParams > Why should this go into a "commons"? I agree that "commons" isn't the right concept. This is really configuration stuff, which generally needs to be available to all of the modules. > > apps/FOFileHandler and apps/InputHandler could logically go > into the FO Tree > > package. > I don't think so. They are abstractions for the Processor input and > don't have anything to do with the FO tree. My preference would really be to put them in a "parse" package. We have kind of lumped parsing in with FO Tree building as a practical matter, hence my comment. Since we have the Structure Renderers, we really have parsing without FO Tree building. One possibility would be to create an apps.common (or whatever) package to throw this stuff into. That way the build process could distinguish them, but would still be picked up in apps (this would solve Glen's concern about FOException as well). Conclusion: We have three active committers right now, one positive, one negative, one lukewarm, so I will abandon the enforcement idea. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo isolation complete (almost)
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
Re: fo isolation complete (almost)
Victor Mote wrote: [interesting stuff] Package1 2 3a 3b 4 tools| | | x | | | Should be 4 (apps) module, I think. util | x | | | | | Uh, I never liked that. Here is my +1. +0 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 +1 apps/FOUserAgent ??? apps/FOFileHandler apps/InputHandler Should stay in apps pdf/PDFEncryptionParams Why should this go into a "commons"? apps/FOFileHandler and apps/InputHandler could logically go into the FO Tree package. I don't think so. They are abstractions for the Processor input and don't have anything to do with the FO tree. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo isolation complete (almost)
--- 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]
RE: fo isolation complete (almost)
Victor Mote wrote: > If we come to general agreement that subdiving FOP this way is good, I'll ^ Sorry, this word should be "subdividing". Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
