xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Pepping <spepp...@leverkruid.nl>
Subject Re: Switch from AddLMVisitor to FObj.addLayoutManager()
Date Mon, 02 Aug 2004 19:18:57 GMT
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

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 <bowditch_chris@hotmail.com> 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

View raw message