Layout simplifications

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Layout simplifications

gmazza
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

Reply | Threaded
Open this post in threaded view
|

Re: Layout simplifications

Luca Furini
Glen Mazza wrote:

> [...]
> 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.

It seems a good plan; maybe it would be better to wait a little time, so
that the code is more or less stabilized.

As we are talking about code simplifications: at the moment there are
classes for the sequences of elements (KnuthSequence, extended by
Paragraph and BlockSequence) and for the breaking algorithms
(BreakingAlgorithm, PageBreakingAlgorithm, LineBreakingAlgorithm).

The sequences and the algorithms are tightly coupled, and they share (or
duplicate) many parameters: what about having a class with both the
sequence of elements and its specific breaking method?

Regards
    Luca



Reply | Threaded
Open this post in threaded view
|

Re: Layout simplifications

gmazza
In reply to this post by gmazza
Hi Luca,

Thanks for the support!!!  I am resurrecting this
idea.  I do think the insights gained will be
considerable--and the resultant architecture will
become more streamlined, rigorous, and more respected
by the people that FOP needs to look good to.

I did 28 CVS commits on the Knuth branch--a couple
needed reverting, but in general I'm happy with the
before-and-after as well as the quality of email
conversations it engendered. I wish to continue the
work.

But, yes, we can wait a (little!) bit on this and the
simplification you mention below also sounds like a
good idea.

Regards,
Glen


----- Original Message -----
From: "Luca Furini" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, May 18, 2005 12:57 PM
Subject: Re: Layout simplifications


> Glen Mazza wrote:
>
> > [...]
> > 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.
>
> It seems a good plan; maybe it would be better to
wait a little time, so
> that the code is more or less stabilized.
>
> As we are talking about code simplifications: at the
moment there are
> classes for the sequences of elements
(KnuthSequence, extended by
> Paragraph and BlockSequence) and for the breaking
algorithms
> (BreakingAlgorithm, PageBreakingAlgorithm,
LineBreakingAlgorithm).
>
> The sequences and the algorithms are tightly
coupled, and they share (or
> duplicate) many parameters: what about having a
class with both the
> sequence of elements and its specific breaking
method?
>
> Regards
>     Luca
>
>
>