Finn Bock wrote:
[Glen]
Does anyone have a problem if I worked towards
removing the initialize() method from our
LayoutManager interface?
There is two way of looking at it. The code in initProperties() which can be moved to the ctor should be. That is no loss at all and will reduce complexity of the LMs a tiny bit.
Yes, any initialization that the LM can do internally I'd like to get out of initProperties(), so I can better see where external initialization is needed.
BTW, we're down to four usages, of which I think three I can easily move to the constructor [1], [2], [3]. (Please glance at them and see if you see anything obvious that would suggest otherwise.) I'm thinking this way because I believe the new implementation of the properties keeps the values of the particular traits being called immutable.
[1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java?annotate=1.32#76
[2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/InlineLayoutManager.java?annotate=1.2#54
[3] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java?annotate=1.26#67
The fourth LM [4] I believe is being reused for multiple fo:blocks during processing--and uses initProperties() to update its state--so this one will take more scrutiny. I would like that classes' initProperties() to be renamed to something more self-documenting, such as reloadTraitsForNextFOBlock() or something similar. But this one can be looked at later.
[4] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java?annotate=1.32#77
Thanks, Glen
