The code is still hot, although not as hot as when you tried first time. Simon
On Mon, May 16, 2005 at 09:13:51PM -0400, Glen Mazza wrote: > trying again... > > -------- Original-Nachricht -------- > Betreff: Layout simplifications > Datum: Mon, 16 May 2005 18:14:52 -0400 > Von: Glen Mazza <[EMAIL PROTECTED]> > An: [email protected] > > > > Team, > > Currently the LM classes that use the Knuth breaking strategy employ the > breaking via a nested (inner) class -- > PageSequenceLayoutManager.PageBreaker, for example. This is causing > some duplication in methods (getNextKnuthElements(), for example) and > variables in each of the Breaker classes. Also, AbstractBreaker has to > duplicate methods already available in AbstractLayoutManager because it > does not extend it. > > What I would like to do is the following (step-by-step, not proceeding > until each stage works): > > 1.) Have AbstractBreaker extend AbstractLayoutManager (ALM). > > 2.) Remove the PageBreaker inner class from PSLM, and have PSLM > directly extend AbstractBreaker. Refactor and remove any duplicate > methods and variables. > > 3.) Rename AbstractBreaker to AbstractBreakingLayoutManager (or similar). > > 4.) One by one, remove the nested inner classes from those other > breaking LM classes: removing any duplicate methods or functionality > already available in the base class, and having those classes extend > ABLM instead of ALM. (Only those LM classes which do breaking will > extend ABLM--the rest will continue with ALM.) > > 5.) Refactor/simplify AbstractBreakingLayoutManager, taking advantage > of methods already available in AbstractLayoutManager. > Refactor/simplify the ABLM-extended classes, again resulting from > insights during this process. > > 6.) (possibly) Create a BreakingLayoutManager interface (extending > LayoutManager interface?), just to keep note of the delta between ABLM > and ALM. > > I think if we do this, it will allow for more simplifications and > insights into the layout coding, and make it easier to understand. I > don't think we can afford the duplication as-is--my experience so far > with FOP is that simplifying engenders more simplifications, while lard > ends up begetting more lard. > > Thoughts/comments? > > Thanks, > Glen > > > -- Simon Pepping home page: http://www.leverkruid.nl
