----- Original Message -----
From: "Finn Bock" <[EMAIL PROTECTED]>
To: <[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
is
> > 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
been
> > thinking about more elegant solution which would allow me to track a
mapping
> > between FObjs and Areas in cases I need it. I know that any technique
which
> > would force this connection in standard processing would not be
possible,
> > 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
with
> > 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
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
about
> > 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
this
> > 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
FOP's
> > 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.
Thanks,
Tibor Vyletel
ICQ# 79458455
