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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
