Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Well, Finn's proposal is certainly looking nicer with the new LM classes, as it would have far less layout logic it would need to contain. If we can get it down to one file, resembling our FOElementMapping class, nothing but makers and devoid of layout logic, that would be OK with me. Not my favorite design, but not bad either and may possibly be of use as Finn is saying. This can be done anytime--so give me a few more weeks to get the LM business logic shifted over and make sure we run out of ideas/inspiration with the current setup. Then we can place a maker class in (providing someone will redo it!) Glen --- Simon Pepping [EMAIL PROTECTED] wrote: I prefer Finn's proposal, as it promises to make a cleaner separation between the FO and layout modules. Regards, Simon
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. Right now I just have to replace AddLMVisitor (and the XXXLayoutManager classes). As far as I understand your proposal, I would have to replace FOElementMapping and subclass the FO tree classes in order to plug in a new set of XXXLayoutManager classes. I'm all for simpler code, as long as it does eliminate too many of the features that I use wink. BTW, thanks again for dropping the HEAD code base from 900 to 600 classes and getting rid of all that autogenerated code. You have definitely made FOP more accessible to the programming masses! Curiously, that was never my goal. I just wanted to reduce the amount of mailing list discussions on the topic of generated code. regards, finn
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
--- Finn Bock [EMAIL PROTECTED] wrote: Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is somewhat more difficult--it's not insurmountable--and compared to the vast complexity of creating a layout subsystem--almost noise level. It will be a few more headaches, but you'll have a better LS in HEAD to base your code off of as a result. Right now I just have to replace AddLMVisitor (and the XXXLayoutManager classes). As far as I understand your proposal, I would have to replace FOElementMapping and subclass the FO tree classes in order to plug in a new set of XXXLayoutManager classes. Yes, but all this is not one-half percent the complexity or difficulty of developing a brand new alternative strategy to begin with (assuming it will take at least 201 days, and one day for these headaches). I'm seeing the increase in patches to FOP that will result in this change as a greater benefit*, because (1) only the severe minority of FOP users create their own layout strategies while the majority benefits from a faster-created 1.0, and (2) more patches give alternative LS people more and better code for them to base their work on, and in some cases may even remove the need to have an alternative LS at all. *You are a good example, because if it's more difficult for you to create an alternative, you'll be more likely to come back to FOP and start making improvements to HEAD's layout strategy! GOOD! (Please do!) I would rather you work on FOP than on a competitor for it. Glen
(partial retreat) Re: Switch from AddLMVisitor to FObj.addLayoutManager()
I have just noticed another issue. For perhaps 5-10 of the FO's, there actually *was* a lot of layout-specific code within the FO's that probably shouldn't have been there. Mostly this was because of the use of anonymous subclasses. (See [1] for an example of what Victor was able to remove--especially note the area-specific import statements that had to be included under the old method.) I agree with Victor--indeed everyone--in its removal from the FO's, at least to this extent, but would rather create new LM classes--subclassing others as appropriate--in the LM package in order to get this logic out. (I'm surprised this wasn't done in the original code, so I may still be missing something here.) When addLayoutManager() is called, have the FO check its internal state to see if it needs an LM, if so, have it choose one and initialize its constructor, but it should stop there--there shouldn't be layout/formatting code within the FO. Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumberCitation.java?r1=1.12r2=1.8diff_format=h --- Glen Mazza [EMAIL PROTECTED] wrote: --- Finn Bock [EMAIL PROTECTED] wrote: Glen Mazza wrote: I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem.
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
[Glen Mazza] I still prefer my solution. Ok, but please consider that it will then become somewhat more difficult to add an alternative layout subsystem. [Glen Mazza] Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is somewhat more difficult--it's not insurmountable--and compared to the vast complexity of creating a layout subsystem--almost noise level. It will be a few more headaches, but you'll have a better LS in HEAD to base your code off of as a result. IMHO the closer integrated FO tree and LM tree classes is a worse starting point. Victor had the right intentions on this. [...]. I'm seeing the increase in patches to FOP that will result in this change as a greater benefit*, because (1) only the severe minority of FOP users create their own layout strategies while the majority benefits from a faster-created 1.0, and (2) more patches give alternative LS people more and better code for them to base their work on, and in some cases may even remove the need to have an alternative LS at all. You seems to assume that the one default layout system in FOP can satisfy all requirements. I doubt that. The default layout system should be good but it shouldn't try solve everything perfectly IMO. Perhaps Jörg disagree wink. *You are a good example, because if it's more difficult for you to create an alternative, you'll be more likely to come back to FOP and start making improvements to HEAD's layout strategy! GOOD! (Please do!) I would rather you work on FOP than on a competitor for it. My alternative layout subsystem isn't an alternative to FOP but an alternative way of implementing the getNextBreakPoss() code. I do not yet know if anything will come of it but it looks quite promising. If it works, I'll post it as a patch for discussion. regards, finn
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Glen Mazza wrote: Team, While I'm implementing the validateChildNode() methods, I would also like to work on removing the AddLMVisitor visitor pattern[1], and revert to our previous method of having the FO's themselves setup the LayoutManagers via addLayoutManager(). (See here [2][3][4] for examples of the previous way of a year ago.) I would consider that a small step backwards because I liked the seperation between the FO tree and the LM tree. But I have no great love for the AddLMVisitor so I wouldn't mind at all if it disappeared. But instead of putting all the LM strategy code into the FO tree classes, I would suggest that the creation of the LM tree are done with a LayoutManagerMapping and a series of Maker classes, one for each FO class. I'll upload a patch to demonstrate the idea. regards, finn
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
I still prefer my solution. Yours seems to be making things more complex (i.e., replacing one class with 29 others by my count) rather than simpler. (Don't forget, not everybody has an IQ as high as yours--some of us need fewer moving parts to be productive! ;) Please review the thread again to understand my concerns here. BTW, thanks again for dropping the HEAD code base from 900 to 600 classes and getting rid of all that autogenerated code. You have definitely made FOP more accessible to the programming masses! Regards, Glen --- Finn Bock [EMAIL PROTECTED] wrote: Glen Mazza wrote: Team, While I'm implementing the validateChildNode() methods, I would also like to work on removing the AddLMVisitor visitor pattern[1], and revert to our previous method of having the FO's themselves setup the LayoutManagers via addLayoutManager(). (See here [2][3][4] for examples of the previous way of a year ago.) I would consider that a small step backwards because I liked the seperation between the FO tree and the LM tree. But I have no great love for the AddLMVisitor so I wouldn't mind at all if it disappeared. But instead of putting all the LM strategy code into the FO tree classes, I would suggest that the creation of the LM tree are done with a LayoutManagerMapping and a series of Maker classes, one for each FO class. I'll upload a patch to demonstrate the idea. regards, finn
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Glen Mazza wrote: Well, the number of patches and enhancements made to layout/rendering has only been about 2-3 per month in the 12 months that we've had AddLMVisitor. FOP won't finish at that rate, and that *will* affect the users. I agree that FOP wont finish at its current rate of development! Not sure how to change this and still keep a roof over my head. LOL In the 24 months preceding that change (i.e., the original design I'm recommending we return to), I believe it was several times higher, perhaps an average of 25 changes per month. Also, the developers at that time seemed to obtain a much higher grokkage of the layout/rendering code base. The statistics dont tell the full story. The reason the patch rate was so much higher before the Visitor pattern was introduced is because Keiron (one of the main architects of the redesign) was allowed to work on FOP as part of his paid job, and he seemed to disappear not long before Victor started his modularization efforts. Also because the maintenance code had not yet been frozen (of course, you might not be including patches to branches in your statistics) Nice things happen when you drop the IQ needed to work in the code--and simplifications have a habit of begetting more simplifications, as relationships that were previously obscured/unknown become clearer.[1] I tend to agree, but I personally dont find the Vistor pattern the reason the code is so complex. Its the getNextBreakPoss/addAreas methods in TextLM and LineLM that are scarey. In other words, I may be able to propose even more simplifications after this on things I currently can't see with the code as it is. Let's try to get this system down to something that a 12 year old can finish in a weekend. (I believe Victor has one he can lend us as a guinea pig.) Ouch! At any rate, given that most FO's generate and/or return areas (per the Rec), I don't have a problem with one selecting and initializing its own LayoutManager. That is basically what happens anyway, even with the middle man in between. I dont have a problem with that either. I remain -0 on this change. Chris
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
--- Chris Bowditch [EMAIL PROTECTED] wrote: Its the getNextBreakPoss/addAreas methods in TextLM and LineLM that are scarey. Yes, that code is very complex (I wasn't able to fix a problem with the space-after property despite much effort), and I'm not sure there's anything that can be done to make it simpler. Fortunately, some (Simon, Luca) appear to be able to work better with it. Glen
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
On Tue, Aug 03, 2004 at 04:45:58AM -0700, Glen Mazza wrote: --- Chris Bowditch [EMAIL PROTECTED] wrote: Its the getNextBreakPoss/addAreas methods in TextLM and LineLM that are scarey. Yes, that code is very complex (I wasn't able to fix a problem with the space-after property despite much effort), and I'm not sure there's anything that can be done to make it simpler. Fortunately, some (Simon, Luca) appear to be able to work better with it. The getNextBreakPoss/addAreas methods in TextLM and LineLM are scary indeed, probably because they try to deal with so many cases. I believe Luca's patch made the logic much cleaner. Unfortunately, that method has not yet been extended to the descendant LMs. And that seems a more important problem, the difficulty of programming the LM setup with its two passes, getNextBreakPoss and addAreas, over the LM tree. I believe it must be made simpler to allow a decent Java programmer to add code to the layout system. It is an aspect I want to pay attention to, but I will take it slowly and cautiously. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Victor Mote wrote: J.Pietschmann wrote: Well, the real stakeholders (aka users) are probably more interested in working footnotes, or multi-column layout. I don't understand. More interested in working footnotes or multi-column layout than what? Is removing AddLMVisitor an advancement in getting footnotes or multi-column layout working better? Are you reminding us of your neutrality on modularity? Or are you saying that this kind of question is irrelevant? Please let me remind you that I was responding to a direct question. I think Joerg was saying that the details of the code are irrelevant to the end user. I tend to agree with this point, and see no benefit in removing tbe AddLMVisitor stuff. So I have to vote -0 as well. Chris
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Well, the number of patches and enhancements made to layout/rendering has only been about 2-3 per month in the 12 months that we've had AddLMVisitor. FOP won't finish at that rate, and that *will* affect the users. In the 24 months preceding that change (i.e., the original design I'm recommending we return to), I believe it was several times higher, perhaps an average of 25 changes per month. Also, the developers at that time seemed to obtain a much higher grokkage of the layout/rendering code base. Nice things happen when you drop the IQ needed to work in the code--and simplifications have a habit of begetting more simplifications, as relationships that were previously obscured/unknown become clearer.[1] In other words, I may be able to propose even more simplifications after this on things I currently can't see with the code as it is. Let's try to get this system down to something that a 12 year old can finish in a weekend. (I believe Victor has one he can lend us as a guinea pig.) At any rate, given that most FO's generate and/or return areas (per the Rec), I don't have a problem with one selecting and initializing its own LayoutManager. That is basically what happens anyway, even with the middle man in between. Glen [1] http://www.extremeprogramming.org/rules/refactor.html --- Chris Bowditch [EMAIL PROTECTED] wrote: I think Joerg was saying that the details of the code are irrelevant to the end user. I tend to agree with this point, and see no benefit in removing tbe AddLMVisitor stuff. So I have to vote -0 as well. Chris
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
I would rather remain silent in this acrimonious debate, but I suppose that would not help. I am in favour of a modular view of FOP: - input specification - layout - rendering I am in favour of reusability of the components. It would be good if the layout engine could be applied to different input specs, and if the renderers could be applied to the area tree resulting from a different layout engine. Therefore I am not in favour of removing the AddLMVisitor code. But reusable modules require a good interface between them, and I am not sure FOP has that. The current visitor pattern code in FOP is rather dead, without a proponent in the FOP team, and without active usage for it. Therefore I will not defend the code. The visitor pattern should not be in the way of understanding the layout code. The layout engine should be understandable in and by itself, without the need to see how it is connected to the FO tree. The visitor pattern is almost entirely contained in LMIter. This class presents a sort of iterator which provides the next child LM, and encapsulates how this is precisely achieved. All in all, I am much more concerned about a clean separation of modules. If they have a clear API between them, pluggability can follow. My vote is 0. Regards, Simon On Mon, Aug 02, 2004 at 11:31:59AM -0700, Glen Mazza wrote: Well, the number of patches and enhancements made to layout/rendering has only been about 2-3 per month in the 12 months that we've had AddLMVisitor. FOP won't finish at that rate, and that *will* affect the users. In the 24 months preceding that change (i.e., the original design I'm recommending we return to), I believe it was several times higher, perhaps an average of 25 changes per month. Also, the developers at that time seemed to obtain a much higher grokkage of the layout/rendering code base. Nice things happen when you drop the IQ needed to work in the code--and simplifications have a habit of begetting more simplifications, as relationships that were previously obscured/unknown become clearer.[1] In other words, I may be able to propose even more simplifications after this on things I currently can't see with the code as it is. Let's try to get this system down to something that a 12 year old can finish in a weekend. (I believe Victor has one he can lend us as a guinea pig.) At any rate, given that most FO's generate and/or return areas (per the Rec), I don't have a problem with one selecting and initializing its own LayoutManager. That is basically what happens anyway, even with the middle man in between. Glen [1] http://www.extremeprogramming.org/rules/refactor.html --- Chris Bowditch [EMAIL PROTECTED] wrote: I think Joerg was saying that the details of the code are irrelevant to the end user. I tend to agree with this point, and see no benefit in removing tbe AddLMVisitor stuff. So I have to vote -0 as well. Chris -- Simon Pepping home page: http://www.leverkruid.nl
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Victor Mote wrote: I don't understand. More interested in working footnotes or multi-column layout than what? Is removing AddLMVisitor an advancement in getting footnotes or multi-column layout working better? Are you reminding us of your neutrality on modularity? Or are you saying that this kind of question is irrelevant? Please let me remind you that I was responding to a direct question. I know. I just loathe heated debates around topics which are, from the viewpoint of an end user, a side show. Modularity is nice to have, but if there aren't any modules which actually do the real work, users hardly care. I wish everybody would expend the energy on more pressing issues. J.Pietschmann
RE: Switch from AddLMVisitor to FObj.addLayoutManager()
Glen Mazza wrote: While I'm implementing the validateChildNode() methods, I would also like to work on removing the AddLMVisitor visitor pattern[1], and revert to our previous method of having the FO's themselves setup the LayoutManagers via addLayoutManager(). (See here [2][3][4] for examples of the previous way of a year ago.) I believe this change will help make the fundamental relations between the AreaTreeHandler, the formatting objects, and the layout managers a bit easier to see, and will hopefully lead to making layout less complex. (Architecturally, I'm also not too pleased with the large amount of FO- and LM-specific business logic that AddLMVisitor ends up needing to retain.) We haven't had any demand yet for the visitor pattern, and we can always place it in later if needed after the FO/Layout business logic has been better determined. Any objections? -0. I'm sorry you asked (again), but since you did, of course I object. The 0 is because I am not a FOP stakeholder, but the - is because I am a Friend of FOP. In exchange for making layout a bit easier you will be putting layout logic in the FO Tree. How can it possibly lead to making layout less complex? Nor do I see either the large amount of FO- and LM-specific business logic that AddLMVisitor ends up needing to retain or why this would be important. Maybe I am missing something here, but when you have no presentation layer and no database, isn't pretty much everything business logic? I guess a case can be made that the presentation layer is the area tree and the data layer is the FOTree. That would make the layout engine the business logic. If that is true, then you are getting ready to take the business logic that is now in layout (where it belongs) and moving it back to the FOTree. Maybe you could start by telling us how someone who insists on a monolithic design even cares where business logic resides. Now, in all honesty, there are other ways (besides the Visitor pattern) to obtain the separation I was seeking. If I had known that the Visitor pattern would be received as being monstrously complex, I think I would have chosen another option, and I have no objection to changing to one of those now. However, this is well-fought territory, and I have no further interest in its outcome. I mention it only to point out the *real* issue in case any real FOP stakeholders are interested. It takes a special kind of logic to deliberately set out to make something less flexible than it was, to reduce the number of options available. However, that is the FOP company line, and I am the one who is out of step with it. FOP's development strategy appears to continue to be wholly staked on the imminent successful release of the new layout system. Anything that is done to reduce the options to only that one must result in the maximum resources being bent toward that goal, right? Is anyone familiar with the economic concept of Unintended Consequences? I don't mean for this to be a rant, nor do I want it to slow anyone down. I just want to make very sure that no one thinks I agree with this stuff, especially when no convincing case has ever been put forth that it is a Good Thing. Victor Mote
Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Victor Mote wrote: I mention it only to point out the *real* issue in case any real FOP stakeholders are interested. Well, the real stakeholders (aka users) are probably more interested in working footnotes, or multi-column layout. J.Pietschmann
RE: Switch from AddLMVisitor to FObj.addLayoutManager()
J.Pietschmann wrote: Well, the real stakeholders (aka users) are probably more interested in working footnotes, or multi-column layout. I don't understand. More interested in working footnotes or multi-column layout than what? Is removing AddLMVisitor an advancement in getting footnotes or multi-column layout working better? Are you reminding us of your neutrality on modularity? Or are you saying that this kind of question is irrelevant? Please let me remind you that I was responding to a direct question. Victor Mote
Switch from AddLMVisitor to FObj.addLayoutManager()
Team, While I'm implementing the validateChildNode() methods, I would also like to work on removing the AddLMVisitor visitor pattern[1], and revert to our previous method of having the FO's themselves setup the LayoutManagers via addLayoutManager(). (See here [2][3][4] for examples of the previous way of a year ago.) I believe this change will help make the fundamental relations between the AreaTreeHandler, the formatting objects, and the layout managers a bit easier to see, and will hopefully lead to making layout less complex. (Architecturally, I'm also not too pleased with the large amount of FO- and LM-specific business logic that AddLMVisitor ends up needing to retain.) We haven't had any demand yet for the visitor pattern, and we can always place it in later if needed after the FO/Layout business logic has been better determined. Any objections? Thanks, Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/AddLMVisitor.java?rev=1.44view=auto [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/InstreamForeignObject.java?annotate=1.4#93 [3] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/ExternalGraphic.java?annotate=1.3#110 [4] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumber.java?annotate=1.8#114
