Disconnect PSLM from LayoutManager interface?

[Glen Mazza <gm...@apache.org>]

Team,

This issue is somewhat messy because it involves two parts--but I'll try 
to keep it succinct:

1.)  The connections between PSLM and 
AbstractLayoutManager/LayoutManager have been so reduced that it would 
appear now to be a simpler and more robust design to make PSLM 
standalone (i.e., not even have it implement the LayoutManager 
interface.)  By extending ALM, PSLM is presently sitting on 250-300 LOC 
that it is not using (with the apparently erroneous exception of one 
empty method, the second issue below.)  None of the 15 methods in the LM 
interface are needed by PSLM today in order to do it duties--so I wonder 
if we should go ahead and remove it (pending #2 below).

2.)  The only remaining exception to being able to sever PSLM from LM is 
the method "LayoutManager getTopLevelLM()" within PSLM's PageBreaker. 
PSLM's implementation returns itself here, which therefore requires PSLM 
to be a LayoutManager.

Problem here is that the Breaking mechanism doesn't appear to be doing 
much at all with the PSLM variable.  Tracing the code, the only thing 
the PageBreaker is asking of the PSLM is a call to addAreas() -- which 
is defined to be empty for PSLM anyway.  I don't see why the page 
breaking code needs the PSLM--looking at the Page Breaker code, it 
appears it gets everything it processes from the childFLM.

Can this getTopLevelLM() be rewritten to eliminate the need to supply 
the pslm object to the PageBreaker?  Either (a) just return NULL in 
PSLM's implementation, (b) return the childFLM (similar to 
StaticContentBreaker's subclass, which returns the sclm for this 
method), or even (c) replace the method entirely with addAreasFromLM() 
(this apparently being the only thing requested after getTopLevelLM() 
anyway), for which PSLM can just return NULL?

We may decide, for various reasons (loss of symmetry perhaps), not to 
separate PSLM from LM anyway.  And I certainly wouldn't want the code 
base deformed in order to artifically do this separation.  But I also 
wouldn't want us to be *forced* to keep PSLM a LM due to what may be an 
incorrect or suboptimal implementation of getTopLevelLM() in the page 
breaking code.

Thoughts/Comments?

Thanks,
Glen