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
> 

Reply via email to