StaticContentLayoutManager

[Victor Mote <vi...@outfitr.com>]

FOP Developers:

I just committed a change (for the FO isolation work) that may have broken
my general rule of not changing the substance of what is going on in the
code. The fo/pagination/StaticContent stored a reference to a
StaticContentLayoutManager and returned that when one was needed, only
creating a new one if the stored one was null. Because the fo classes should
no longer see the layout classes, I removed the field, and simply make the
method return a new LM when one is needed. This may actually be OK, as this
is the behavior of most of the other methods that create LMs.

I anticipated that we might need an interface in FO that could be used for
objects that wished to embed themselves into an FO Tree object, for example
if the layout system wanted to cross-reference one of its objects with an
object in the FO Tree. However, with the exception of the StaticContent item
mentioned above, I haven't seen a need for it yet, and have decided to defer
adding the interface until we are sure we need it.

I wanted to alert you to this, in case someone knows of a problem that this
has created. AFAIK, the worst problem is probably that we may have a few too
many StaticContentLayoutManagers being created. My simple basic regression
tests did not reveal any problems.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org