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
>
>
