(partial retreat) Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

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.12&r2=1.8&diff_format=h

--- Glen Mazza <gr...@yahoo.com> wrote:

> --- Finn Bock <bc...@worldonline.dk> 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.
> > 
>