Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

Team,

While I'm implementing the validateChildNode()
methods, I would also like to work on removing the
AddLMVisitor visitor pattern[1], and revert to our
previous method of having the FO's themselves setup
the LayoutManagers via addLayoutManager().  (See here
[2][3][4] for examples of the previous way of a year
ago.)  

I believe this change will help make the fundamental
relations between the AreaTreeHandler, the formatting
objects, and the layout managers a bit easier to see,
and will hopefully lead to making layout less complex.
 (Architecturally, I'm also not too pleased with the
large amount of FO- and LM-specific business logic
that AddLMVisitor ends up needing to retain.)

We haven't had any demand yet for the visitor pattern,
and we can always place it in later if needed after
the FO/Layout business logic has been better
determined.  Any objections?

Thanks,
Glen


[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/AddLMVisitor.java?rev=1.44&view=auto

[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/InstreamForeignObject.java?annotate=1.4#93

[3]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/ExternalGraphic.java?annotate=1.3#110

[4]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumber.java?annotate=1.8#114

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

Well, Finn's proposal is certainly looking nicer with
the new LM classes, as it would have far less layout
logic it would need to contain.  If we can get it down
to one file, resembling our FOElementMapping class,
nothing but makers and devoid of layout logic, that
would be OK with me.  Not my favorite design, but not
bad either and may possibly be of use as Finn is
saying.

This can be done anytime--so give me a few more weeks
to get the LM business logic shifted over and make
sure we run out of ideas/inspiration with the current
setup.  Then we can place a maker class in (providing
someone will redo it!)

Glen

--- Simon Pepping <sp...@leverkruid.nl> wrote:
> 
> I prefer Finn's proposal, as it promises to make a
> cleaner separation
> between the FO and layout modules.
> 
> Regards, Simon
> 

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Simon Pepping <sp...@leverkruid.nl>]

On Thu, Aug 05, 2004 at 08:31:59PM -0700, Glen Mazza wrote:
> I still prefer my solution.  Yours seems to be making
> things more complex (i.e., replacing one class with 29
> others by my count) rather than simpler.   (Don't
> forget, not everybody has an IQ as high as yours--some
> of us need fewer moving parts to be productive! ;) 
> Please review the thread again to understand my
> concerns here.

I prefer Finn's proposal, as it promises to make a cleaner separation
between the FO and layout modules.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

--- Finn Bock <bc...@worldonline.dk> wrote:
> 
> My alternative layout subsystem isn't an alternative
> to FOP but an 
> alternative way of implementing the
> getNextBreakPoss() code.
> 
> I do not yet know if anything will come of it but it
> looks quite 
> promising. If it works, I'll post it as a patch for
> discussion.
> 

And also, if you have the time to glance at Luca's
work, that would be great.

Glen

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Finn Bock <bc...@worldonline.dk>]

[Glen Mazza]

>>>I still prefer my solution.
>>
>>Ok, but please consider that it will then become
>>somewhat more difficult 
>>to add an alternative layout subsystem.

[Glen Mazza]

> Layout subsystems are much rarer than people think, so
> not that much a concern IMO.  Keyword here is
> "somewhat more difficult"--it's not
> insurmountable--and compared to the vast complexity of
> creating a layout subsystem--almost noise level.  It
> will be a few more headaches, but you'll have a better
> LS in HEAD to base your code off of as a result.

IMHO the closer integrated FO tree and LM tree classes is a worse 
starting point. Victor had the right intentions on this.

> [...]. I'm seeing the increase in patches to FOP
> that will result in this change as a greater benefit*,
> because (1) only the severe minority of FOP users
> create their own layout strategies while the majority
> benefits from a faster-created 1.0, and (2) more
> patches give alternative LS people more and better
> code for them to base their work on, and in some cases
> may even remove the need to have an alternative LS at
> all.

You seems to assume that the one default layout system in FOP can 
satisfy all requirements. I doubt that. The default layout system should 
be good but it shouldn't try solve everything perfectly IMO. Perhaps 
Jörg disagree <wink>.

> *You are a good example, because if it's more
> difficult for you to create an "alternative", you'll
> be more likely to come back to FOP and start making
> improvements to HEAD's layout strategy!  GOOD! (Please
> do!)  I would rather you work on FOP than on a
> competitor for it.

My alternative layout subsystem isn't an alternative to FOP but an 
alternative way of implementing the getNextBreakPoss() code.

I do not yet know if anything will come of it but it looks quite 
promising. If it works, I'll post it as a patch for discussion.

regards,
finn

(partial retreat) Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

I have just noticed another issue.  For perhaps 5-10
of the FO's, there actually *was* a lot of
layout-specific code within the FO's that probably
shouldn't have been there.  Mostly this was because of
the use of anonymous subclasses.  (See [1] for an
example of what Victor was able to remove--especially
note the area-specific import statements that had to
be included under the old method.)  

I agree with Victor--indeed everyone--in its removal
from the FO's, at least to this extent, but would
rather create new LM classes--subclassing others as
appropriate--in the LM package in order to get this
logic out.  (I'm surprised this wasn't done in the
original code, so I may still be missing something
here.)

When addLayoutManager() is called, have the FO check
its internal state to see if it needs an LM, if so,
have it choose one and initialize its constructor, but
it should stop there--there shouldn't be
layout/formatting code within the FO.

Glen

[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumberCitation.java?r1=1.12&r2=1.8&diff_format=h

--- Glen Mazza <gr...@yahoo.com> wrote:

> --- Finn Bock <bc...@worldonline.dk> wrote:
> > Glen Mazza wrote:
> > 
> > > I still prefer my solution.
> > 
> > Ok, but please consider that it will then become
> > somewhat more difficult 
> > to add an alternative layout subsystem.
> > 
> 

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

--- Finn Bock <bc...@worldonline.dk> wrote:
> Glen Mazza wrote:
> 
> > I still prefer my solution.
> 
> Ok, but please consider that it will then become
> somewhat more difficult 
> to add an alternative layout subsystem.
> 

Layout subsystems are much rarer than people think, so
not that much a concern IMO.  Keyword here is
"somewhat more difficult"--it's not
insurmountable--and compared to the vast complexity of
creating a layout subsystem--almost noise level.  It
will be a few more headaches, but you'll have a better
LS in HEAD to base your code off of as a result.

> Right now I just have to replace AddLMVisitor (and
> the XXXLayoutManager 
> classes). As far as I understand your proposal, I
> would have to replace 
> FOElementMapping and subclass the FO tree classes in
> order to plug in a 
> new set of XXXLayoutManager classes.
> 

Yes, but all this is not one-half percent the
complexity or difficulty of developing a brand new
alternative strategy to begin with (assuming it will
take at least 201 days, and one day for these
headaches).  I'm seeing the increase in patches to FOP
that will result in this change as a greater benefit*,
because (1) only the severe minority of FOP users
create their own layout strategies while the majority
benefits from a faster-created 1.0, and (2) more
patches give alternative LS people more and better
code for them to base their work on, and in some cases
may even remove the need to have an alternative LS at
all. 

*You are a good example, because if it's more
difficult for you to create an "alternative", you'll
be more likely to come back to FOP and start making
improvements to HEAD's layout strategy!  GOOD! (Please
do!)  I would rather you work on FOP than on a
competitor for it.

Glen

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Finn Bock <bc...@worldonline.dk>]

Glen Mazza wrote:

> I still prefer my solution.

Ok, but please consider that it will then become somewhat more difficult 
to add an alternative layout subsystem.

Right now I just have to replace AddLMVisitor (and the XXXLayoutManager 
classes). As far as I understand your proposal, I would have to replace 
FOElementMapping and subclass the FO tree classes in order to plug in a 
new set of XXXLayoutManager classes.

I'm all for simpler code, as long as it does eliminate too many of the 
features that I use <wink>.

> BTW, thanks again for dropping the HEAD code base from
> 900 to 600 classes and getting rid of all that
> autogenerated code.  You have definitely made FOP more
> accessible to the "programming masses"!

Curiously, that was never my goal. I just wanted to reduce the amount of 
mailing list discussions on the topic of generated code.

regards,
finn

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Glen Mazza <gr...@yahoo.com>]

I still prefer my solution.  Yours seems to be making
things more complex (i.e., replacing one class with 29
others by my count) rather than simpler.   (Don't
forget, not everybody has an IQ as high as yours--some
of us need fewer moving parts to be productive! ;) 
Please review the thread again to understand my
concerns here.

BTW, thanks again for dropping the HEAD code base from
900 to 600 classes and getting rid of all that
autogenerated code.  You have definitely made FOP more
accessible to the "programming masses"!

Regards,
Glen


--- Finn Bock <bc...@worldonline.dk> wrote:

> Glen Mazza wrote:
> > Team,
> > 
> > While I'm implementing the validateChildNode()
> > methods, I would also like to work on removing the
> > AddLMVisitor visitor pattern[1], and revert to our
> > previous method of having the FO's themselves
> setup
> > the LayoutManagers via addLayoutManager().  (See
> here
> > [2][3][4] for examples of the previous way of a
> year
> > ago.)  
> 
> I would consider that a small step backwards because
> I liked the 
> seperation between the FO tree and the LM tree. But
> I have no great love 
> for the AddLMVisitor so I wouldn't mind at all if it
> disappeared.
> 
> But instead of putting all the LM strategy code into
> the FO tree 
> classes, I would suggest that the creation of the LM
> tree are done with 
> a "LayoutManagerMapping" and a series of "Maker"
> classes, one for each 
> FO class.
> 
> I'll upload a patch to demonstrate the idea.
> 
> regards,
> finn
> 

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

[Finn Bock <bc...@worldonline.dk>]

Glen Mazza wrote:
> Team,
> 
> While I'm implementing the validateChildNode()
> methods, I would also like to work on removing the
> AddLMVisitor visitor pattern[1], and revert to our
> previous method of having the FO's themselves setup
> the LayoutManagers via addLayoutManager().  (See here
> [2][3][4] for examples of the previous way of a year
> ago.)  

I would consider that a small step backwards because I liked the 
seperation between the FO tree and the LM tree. But I have no great love 
for the AddLMVisitor so I wouldn't mind at all if it disappeared.

But instead of putting all the LM strategy code into the FO tree 
classes, I would suggest that the creation of the LM tree are done with 
a "LayoutManagerMapping" and a series of "Maker" classes, one for each 
FO class.

I'll upload a patch to demonstrate the idea.

regards,
finn

RE: Switch from AddLMVisitor to FObj.addLayoutManager()

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> While I'm implementing the validateChildNode() methods, I 
> would also like to work on removing the AddLMVisitor visitor 
> pattern[1], and revert to our previous method of having the 
> FO's themselves setup the LayoutManagers via 
> addLayoutManager().  (See here [2][3][4] for examples of the 
> previous way of a year
> ago.)  
> 
> I believe this change will help make the fundamental 
> relations between the AreaTreeHandler, the formatting 
> objects, and the layout managers a bit easier to see, and 
> will hopefully lead to making layout less complex.
>  (Architecturally, I'm also not too pleased with the large 
> amount of FO- and LM-specific business logic that 
> AddLMVisitor ends up needing to retain.)
> 
> We haven't had any demand yet for the visitor pattern, and we 
> can always place it in later if needed after the FO/Layout 
> business logic has been better determined.  Any objections?

-0.

I'm sorry you asked (again), but since you did, of course I object. The "0"
is because I am not a FOP stakeholder, but the "-" is because I am a Friend
of FOP. In exchange for making layout "a bit easier" you will be putting
layout logic in the FO Tree. How can it possibly "lead to making layout less
complex"? Nor do I see either "the large amount of FO- and LM-specific
business logic that AddLMVisitor ends up needing to retain" or why this
would be important. Maybe I am missing something here, but when you have no
presentation layer and no database, isn't pretty much everything business
logic? I guess a case can be made that the presentation layer is the area
tree and the data layer is the FOTree. That would make the layout engine the
business logic. If that is true, then you are getting ready to take the
business logic that is now in layout (where it belongs) and moving it back
to the FOTree. Maybe you could start by telling us how someone who insists
on a monolithic design even cares where business logic resides.

Now, in all honesty, there are other ways (besides the Visitor pattern) to
obtain the separation I was seeking. If I had known that the Visitor pattern
would be received as being monstrously complex, I think I would have chosen
another option, and I have no objection to changing to one of those now.

However, this is well-fought territory, and I have no further interest in
its outcome. I mention it only to point out the *real* issue in case any
real FOP stakeholders are interested. It takes a special kind of logic to
deliberately set out to make something less flexible than it was, to reduce
the number of options available. However, that is the FOP company line, and
I am the one who is out of step with it. FOP's development strategy appears
to continue to be wholly staked on the imminent successful release of the
new layout system. Anything that is done to reduce the options to only that
one must result in the maximum resources being bent toward that goal, right?
Is anyone familiar with the economic concept of Unintended Consequences?

I don't mean for this to be a rant, nor do I want it to slow anyone down. I
just want to make very sure that no one thinks I agree with this stuff,
especially when no convincing case has ever been put forth that it is a Good
Thing.

Victor Mote