Disconnect PSLM from LayoutManager interface?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Disconnect PSLM from LayoutManager interface?


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.