Re: remove LayoutManager.initialize()?
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
Re: remove LayoutManager.initialize()?
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
remove LayoutManager.initialize()?
Team, Does anyone have a problem if I worked towards removing the initialize() method from our LayoutManager interface? The relatively few cases in our LM subclasses where we are using it each appear to show that they can initialize themselves -- the method is currently only being used to query traits from an already available FObj, so the need for external initialization isn't apparent to me. I'd rather we move towards subclass-specific initialize() methods for those LM subclasses that need them (currently, appears to be about zero), with comments added as to why external initialization is preferable for those LM's. This would help in better understanding the layout process. Thanks, Glen
RE: remove LayoutManager.initialize()?
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi Glen, Does anyone have a problem if I worked towards removing the initialize() method from our LayoutManager interface? No objections here at first glance, however ... (see below) The relatively few cases in our LM subclasses where we are using it each appear to show that they can initialize themselves -- the method is currently only being used to query traits from an already available FObj, so the need for external initialization isn't apparent to me. Not really sure about this myself, but could the point be to accommodate trait-setting for markers (since these have to be formatted according to the FObj into which they are 'retrieved' --so there we need to be able to query the latter)? In that case, we should, of course, make sure that such functionality remains available to all LMs for the allowed children of markers... which would come down to practically all LMs :-/ Can anyone clarify? Cheers, Andreas
Re: remove LayoutManager.initialize()?
On Wed, Nov 10, 2004 at 06:37:28AM -0800, Glen Mazza wrote: Team, Does anyone have a problem if I worked towards removing the initialize() method from our LayoutManager interface? The relatively few cases in our LM subclasses where we are using it each appear to show that they can initialize themselves -- the method is currently only being used to query traits from an already available FObj, so the need for external initialization isn't apparent to me. I'd rather we move towards subclass-specific initialize() methods for those LM subclasses that need them (currently, appears to be about zero), with comments added as to why external initialization is preferable for those LM's. This would help in better understanding the layout process. I think it is a hook for doing those initialization actions which for some reason cannot be done in the constructor. I have no idea which actions that could be. If you can move all required actions for a new LM object into the constructor, I have no objection to the removal of this method. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: remove LayoutManager.initialize()?
--- Simon Pepping [EMAIL PROTECTED] wrote: I think it is a hook for doing those initialization actions which for some reason cannot be done in the constructor. I have no idea which actions that could be. Even if a few such actions exist--I don't know any yet--I'm thinking those can still be activated internally by the LM, prior to the LM being used, where used is LM-specific. Since so few of these methods are implemented with initialization code anyway, I should be able to find out soon. If you can move all required actions for a new LM object into the constructor, I have no objection to the removal of this method. I think I can (or very similar)--and if it turns out to be needed again for fo:markers as Andreas was thinking (I don't know if it was related to this, but it is possible)--we can place it right back in--but this time, with comments indicating what for and why needed, and maybe with a more descriptive name -- activateForMarkerUsage() or something like that. Thanks, Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/layoutmgr/Attic/LayoutManager.java?r1=1.7r2=1.8diff_format=h
Re: remove LayoutManager.initialize()?
Oops, the link [1] below was the code that originally added initialize() (as init()) into the interface. [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/layoutmgr/Attic/LayoutManager.java?r1=1.7r2=1.8diff_format=h
Re: remove LayoutManager.initialize()?
[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. 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. regards, finn
