Jeremias,
Yes, I'm leaning towards separating PSLM from LayoutManager at least as
a trial. I do know our RootLayoutManager (=ATH) doesn't need it, ATH is
nicely anchored to the floor, and it was *much, much* easier for me to
grok than PSLM (taking into account of course ATH's lesser
functionality.) I'd like us to try it and see what happens for a while,
we can easily move it back if it's a disaster. Groovy things may
happen that I can't predict right now.
[As an aside, fo:flow and fo:static-content are of course both
considered flows by the spec. For that reason, I think we might end up
having both StaticContentLayoutManager and FLM extend a new
AbstractFlowLayoutManager class (which will in turn extend whatever SCLM
and FLM currently extend--BlockStackingLayoutManager I think.) Right
now, it would just have a getPSLM() method in common--but perhaps more
will come into it over time.]
As for the change you mention, you may have misunderstood my concern.
It is most fine and fantastic if the Breaking code needs the PSLM *as* a
PSLM--whatever the processing calls for--I'm just leery of having it
need PSLM *as a LayoutManager* in particular. Something like PSLM
getPSLM() and not LayoutManager getPSLM(). I.e., I would like PSLM to
be able to implement (or not implement) any of 50 different things, and
still have the breaking code work fine with it.
Your code looks good. Go ahead and promote PageViewportProvider if you
like (no, not my taste, but you code your way and I'll code mine. ;-) I
might recommend though, as above, having the method
getPageViewportProvider() be kept within the PSLM, not the PSLM's
PageBreaker. I'd like to keep things a little less restrictive right
now as some code may move back and forth, and so letting the Breaker
code have a PSLM may be useful at this time--so instead we could have a
PageBreaker.getPSLM(), and from there let the AbstractBreaker code call
pslm.getPageViewportProvider().
[Another option, given that getTopLevelLM() up until now isn't doing
anything, is just returning the childFLM object from PageBreaker's
getTopLevelLM(), and then calling childFLM.getPSLM() from that. This
has the elegance of allowing access to the PSLM from StaticContentLM's
Breaker inner class as well (getTopLevelLM().getPSLM()) and other
breaker objects. This change would also better give us the option of
moving PageBreaker to FLM (akin to its sibling SCLM -- albeit with
functions back to PSLM to get the separator areas) should it end up
making more sense.]
Many thanks,
Glen
Jeremias Maerki wrote:
Glen,
this was quite interesting. Right after your change here, my local
changes started to fail. Obviously, my changes for changing BPD between
pages was the first use case for getTopLevelLM() to fetch the PSLM. But
you are likely to remove the LayoutManager interface from PSLM I took a
different route and made the PageViewportProvider available differently.
I hope that was acceptable and still as clean as possible. I was also
thinking about promoting the PageViewportProvider in PSLM to a full
class. But I left it out for now.
