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 <[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. > > >