You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gm...@apache.org> on 2005/05/17 03:13:51 UTC
[Fwd: Layout simplifications]
trying again...
-------- Original-Nachricht --------
Betreff: Layout simplifications
Datum: Mon, 16 May 2005 18:14:52 -0400
Von: Glen Mazza <gm...@apache.org>
An: fop-dev@xmlgraphics.apache.org
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
Re: [Fwd: Layout simplifications]
Posted by Simon Pepping <sp...@leverkruid.nl>.
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 <gm...@apache.org>
> An: fop-dev@xmlgraphics.apache.org
>
>
>
> 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
Re: [Fwd: Layout simplifications]
Posted by Glen Mazza <gm...@apache.org>.
Jeremias Maerki wrote:
>I admit that the AbstractBreaker was simply an artifact from merging in
>Luca's initial code and which later evolved a bit but I began to like
>the distinction between the LMs and the breakers.
>
>
>
OK, we'll keep that distinction then. This would have been a very
time-consuming code change for me to do, and if the team does not see
much benefit to it, it is not worth the effort.
>And as I mentioned before, I prefer getting FOP near a developer release
>over making the code perfect. But I won't stand in your way if you want
>to spend countless hours which result in little more than perfectly
>looking code. There are so many other little things that still need to
>be done but which have a real impact on the end result. Just my honest,
>personal opinion.
>
>
Thanks for implying I can write perfect code. ;-)
Glen
Re: [Fwd: Layout simplifications]
Posted by Glen Mazza <gm...@apache.org>.
Jeremias Maerki wrote:
>AbstractBreaker has maybe two or three methods in common with
>LayoutManager. Furthermore, I see the Breaker as something else than a
>layout manager. I think it would be confusing to merge the two concepts.
>The duplicate methods can probably be moved up to the base class.
>
>
I've been looking again at the code--I think I agree with you now. I
like how the breakers accumulate all of the breaker-specific methods in
one place in the class. It is cleaner (compared to having them mixed
within the LM classes), and the code is actually quite efficiently
written already.
As for possible duplicate methods such as getNextKnuthElements()--which
is apparently different between the Breaker and the LM in some cases
anyway--I notice that we already have a getTopLevelLM() which returns
the LM getting processed. Where duplication occurs, we can just
reference the method from there (i.e.,
getTopLevelLM().methodInTheLMClass()).
If helpful, we may also want to create more specialized LayoutManager
interfaces (e.g., BreakableLM extending LayoutManager), and then have
certain LM's implement it in addition to whatever they already extend.
If we do that, then we'll have:
BreakableLM getTopLevelLM();
instead to call those only-a-few-LM's-have methods. But I currently
don't see any need to alter the Breaker classes themselves.
Thanks,
Glen
Re: [Fwd: Layout simplifications]
Posted by Jeremias Maerki <de...@greenmail.ch>.
AbstractBreaker has maybe two or three methods in common with
LayoutManager. Furthermore, I see the Breaker as something else than a
layout manager. I think it would be confusing to merge the two concepts.
The duplicate methods can probably be moved up to the base class.
I admit that the AbstractBreaker was simply an artifact from merging in
Luca's initial code and which later evolved a bit but I began to like
the distinction between the LMs and the breakers.
And as I mentioned before, I prefer getting FOP near a developer release
over making the code perfect. But I won't stand in your way if you want
to spend countless hours which result in little more than perfectly
looking code. There are so many other little things that still need to
be done but which have a real impact on the end result. Just my honest,
personal opinion.
On 17.05.2005 03:13:51 Glen Mazza wrote:
> 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
>
>
Jeremias Maerki