----- Original Message ----- 
From: "Finn Bock" <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 10:17 PM
Subject: Re: Connection between FObj and Area

> [Tibor Vyletel]
> > Hello Fopsters,
> >
> > I use FOP (dev 1.0) in a bit different scenario as you. My renderer
works in
> > GEF framework. Till now, I have hacked simple change in relevant layout
> > managers:
> >
> > BlockLayoutManager.getParentArea(Area childArea) {
> >     ...
> >     // this creates connection between fobj and curBlockArea:
> >     curBlockArea.addTrait(Trait.ID_AREA, this.fobj);
> >     ...
> > }
> >
> > This solution is just a hack and a maintainance nightmare, as the design
> > constantly changing ;)
>  >
> > I am aware that described construction is breaking memory optimization
> > goals, however I need it to achieve my goal: enable editing after the
> > rendering process and make this editing as responsive as possible.
> >
> > Lately (in fact, after the removal of getID() method from FObj), I've
> > thinking about more elegant solution which would allow me to track a
> > between FObjs and Areas in cases I need it. I know that any technique
> > would force this connection in standard processing would not be
> > because its effects on memory consumption would be relevant.
> >
> > My alternative idea is:
> > - create AreaFactory interface (or abstract class) which would be
> > responsible for creation of areas. Provide default implementating class
> > today's functionality scattered among LMs.
> >     There are to choices how to design this interface:
> >     a) with one strong method: Area createArea(LayoutManager lm, FObj
> > Object constraints)
> >     b) with a set of specialized methods for creation of different area
> > types:
> >         Inline createInline(...) {}
> >         Block createBlock(...) {}
> >         ...
> Would you need to return subclasses of Inline and Block etc? Or would
> you just set various additional traits such as this.fobj?

Yes, my intention is to create subclasses and return them through my own
implementation of AbstractAreaFactory. Although I have to admit that at this
moment I have just one added functionality in these subclasses in mind: they
will be holding a reference to FObj.

> > - refactor instantiation of area objects in layout managers: remove all
> > direct instantiations and replace them with calls to DefaultAreaFactory
> > - solve how to configure AreaFactory before layouting process. Layout
> > managers don't have access to UserAgent so far, so the best method would
> > probably be a pair of static methods:
> Actually, LMs normally has access to the fobj and through that the
> FONode.getUserAgent() method.

Ups, I did not consider this option: Of course, AreaFactory setting through
UserAgent is much more elegant solution than a static method in
AbstractAreaFactory class.

> >     AreaFactory AreaFactory.getFactory()
> >     AreaFactory.setFactory(AreaFactory factory)
> >     and this constructrion in LMs:
> >     currArea = AreaFactory().getFactory().create....
> >
> > When this pattern would be applied, my problem would be simply solved by
> > creation of descendants for some Area classes, which would hold
reference to
> > the FObj data. Default implementation would bring no extra memory
> > consumption and/or relevant speed degradation.
> >
> > The reason why I have written this mail, is to obtain some feedback
> > suggested refactoring. In fact I am forced to do some changes to the FOP
> > code because of my project's special requirements.
> Would you still need to change FOP sources, even after your proposal was
> implemented?

This refactoring (that I want to implement myself and send it to the team as
a patch) would allow me to make parallel (pluginable) implementation of some
Area classes. These new classes would not be a part of the FOP itself, but
would be included in my own packages. In this case, I could develop my own
code and still could be able to use FOP and whole its functionality
(particulary LMs and existing Area classes).

Just to describe my situation now: When I update my local copy of FOP from
your CVS (let's say once a week), I have to make my own build of fop.jar
(where some layout managers contain one special line of code) and then use
this package file in my plugins.

> > The real payback for me
> > would the case when all the maintainance nightmares would be gone and
> > can happen only when creation of Areas is more modular. I think that
> > modularization of this could bring its two cents to the quality of the
> > source code.
>  From your description I sort of get the impression that a smaller
> change, such having all LMs call a new method, say
>     AbstractLayoutManager.setGeneralTraits(FObj)
> which has a default empty implementation. Would it be good enough for
> you to change AbstractLayoutManager to add your special requirements?
> regards,
> finn

Finn, I don't understand how a method line setGeneralTraits(FObj) could help
me. Having such a method would allow me to reduce number of occurences of
the source code line I add to LMs to one place in AbstractLayoutManager, but
still I would have to maintain a source change directly in the FOP's classes
and that's what I try to avoid.


Tibor Vyletel
ICQ# 79458455

Reply via email to