Finn Bock wrote:
But removing the initialize() method will reduce the flexibility that LMs currently has to retrieve information from the parent LM. Perhaps that flexibility is not used at the moment but I suspect that it will be needed to implement the irregular inheritence of properties like text-decoration.
Well, an LM has a parentLM member variable that it can always access. But you may have discovered initialize()'s intended use. In the five cases in the code where initialize() is being called (there's a stray apparently unneeded case in LineLM I'm not counting here), immediately before or after setParent() is also called e.g. [1] [2].
[1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/ContentLayoutManager.java?annotate=1.15#268
[2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java?annotate=1.12#497
[I think the "after" cases like [2] are erroneous BTW--it appears we should be calling setParent() first.]
But for those LM's which may need to have their trait values refreshed whenever a new parent LM is attached, wouldn't it be better for the LM to refresh *itself* internally and automatically whenever setParent() is called, rather than have this resynching be directed externally? (It would appear that a well-designed LM would do this regardless rather than let itself remain in a corrupted state upon a setParent() call.) So, I'm still not convinced on initialize()'s benefits--this appears to be something we should remove now, and bring back once we have a documented use for it (and preferably with a more descriptive name e.g., refreshTraitValues() or something similar.)
Thanks, Glen
