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
