Hello Glen,

I am aware of the LMs' function in the system. The problem is that their
instantiation is hardcoded, too. At least, I don't see any quick method how
to make a descendant of a LM and "plug" this new class (with just a little
change) to the layouter tree. Maybe similar analogy as I described in
previous mail might be applicable in this place, too.

As to the changes in the system's complexity and OOD:
Introducing abstraction during creation of objects is commonly used pattern
in SW design. The change in the FOP system after application of proposed
change would be restricted to creation of two new classes
(AbstractAreaFactory, DefaultAreaFactory) and following refactoring in LMs
of this kind:
    before:                                                    after:
    currBlockArea = new Block()          --> currBlockArea = new
AbstractAreaFactory

.getFactory().createBlock(...)
In the first phase, implementation of "create" method would be trivial:
    DefaultAreaFactory:
    public Block createBlock() {
        return new Block();
    }

I agree, such implementation might not be worth the effort. On the other
hand, whole system is given new parametrizable feature. And secondly,
"create" methods will eventually become larger as a place for reuse of code
common directly after the instantiation of area object (eg:
TraitSetter.add...).

I want to say, that I understand that you might see my request as absolutely
useless. I can just repeat myself: I work in a different scenario. I
appreciate the work your are doing and I use FOP for long time. I want to
use layouting module in future, but my renderer/editor requires multiple
runs on an input document which (usually) changes just a little beween two
renderings. Till now, I have been using the simplest method: I had changed
underlying XML data according to users actions and then invoked full FOP's
run. This solution is very slow when document is larger. The ability to
interact with FObjs in the controller layer (GEF's editparts in my
environment) would be a great help.

Tibor

PS: Euromath project: http://euromath2.sourceforge.net/


----- Original Message ----- 
From: "Glen Mazza" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 7:37 PM
Subject: Re: Connection between FObj and Area


> I'm quite leery of the changes he's proposing at this
> time.  The complexity of the system would shoot
> through the roof, it's not a solid OO/logical design
> (our LayoutManagers are currently responsible for the
> creation of areas, as they should be), and futhermore,
> I find his "more modular" arguments unconvincing,
> suspect at best.
>
> Glen
>
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > Tibor,
> >
> > I will leave the techical side for the devs that are
> > really familiar
> > with this part of FOP. I'm not. Yet, anyway. But I
> > wanted to invite you
> > to share with us your requirements and help with
> > directly improving the
> > code. Even if you're not a committer you are allowed
> > and encouraged to
> > make suggestions. You can also send patches. Maybe
> > someday we may even
> > be able to welcome you in the team.
> >
> > It sounds like you're building an FO editor using
> > FOP in the backrgound.
> > I take it you mean the Eclipse GEF, not the Tigris
> > GEF, right? Can you
> > provide a link to or some info on your project? I'm
> > simply curious.
> >
> > On 29.10.2004 17:35:57 Tibor Vyletel wrote:
> > > 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(...) {}
> > >         ...
> > >
> > > - 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:
> > >     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.
> > 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.
> > >
> > > Best Regards,
> > >
> > > Tibor Vyletel
> > > Slovakia
> >
> >
> >
> > Jeremias Maerki
> >
> >
>
>

Reply via email to