pluggable LMs would be great too. My proposal to pluginate areas originates
in the will to solve (my) problem as easy as possible. Might sound selfish,
however it's not so bad coding tactics, is it? Anyway, I am happy that I
have started this discussion. FOP's rendering phase can be implemented
according to developer's request outside the FOP itself. The layout phase is
a black box, at the moment. Pluggable LMs and/or Areas would change the

As to the requests of external fop-users: I appreciate the possibility to
use someone's else code which does whole XSL-FO layout for me and I am
prepared to develop my requests (and other features, too) and contribute
them in this newsgroup afterwards. I think, that only contributions we can
agree on before I start to implement them will be use of some use for the
FOP itself and for me too.

If we can agree on the interface for pluggable LMs, I can start to implement
this refactoring right away ...

Best regards,

Tibor Vyletel    (not Tybor ;-)
ICQ# 79458455

----- Original Message ----- 
From: "Glen Mazza" <[EMAIL PROTECTED]>
Sent: Monday, November 01, 2004 3:02 AM
Subject: Re: AreaFactory patch

> I'd rather we have pluggable LayoutManagers -- 1.0's
> emphasis and I think our previous agreement with
> Finn/Simon -- than have pluggable Area objects (where
> much of layout used to be in 0.20.5.)  I'm not sure if
> Fop can realistically handle both at this time.
> As for complexity, in our LM's, with Tybor's proposed
> change, instead of just:
> curBlockArea = new Block();
> we would now have:
> curBlockArea = (Block) fobj.getUserAgent().
>    getAreaFactory().create(Block.class, fobj, this);
> instead of:
> viewportBlockArea = new BlockViewport();
> we would now have:
> viewportBlockArea = (BlockViewport)
> fobj.getUserAgent() .getAreaFactory().create
> (BlockViewport.class, fobj, this);
> over and over again.  The question here seems to be:
> should we add this additional complexity to our system
> *now* so Tybor doesn't need to rewrite code every week
> he does a cvs update?  Or have him tolerate it until
> 1.0 is out (when presumably, he can rely on a
> production release and not need to update every week.)
> Personally speaking, I am much more amenable to adding
> some complexity (LM Makers, for example, or opening up
> our validation) if it helps out Finn's work, because
> of the sheer weight of contributions he adds to Fop.
> (We slow him down, we slow down Fop.)  Making these
> changes for someone who isn't submitting
> contributions, however, is less of a concern for me.
> If a user is going to propose a change that would slow
> down system development, we should be getting some
> work to compensate for it, at least during this time
> while we are still building the system.
> My inclination is to have him place this patch in
> Bugzilla, and let's wait until we have others
> requesting it (vs. those who would rather have LM's
> pluggable.)  In the meantime, I think it would be best
> for everyone to keep layout as simple as we can until
> it is done.  I am open to others' opinions however.
> Glen
> --- Tibor Vyletel <[EMAIL PROTECTED]> wrote:
> > Hello Fopsters,
> >
> > I have attached first phase (a working example) of
> > the refactoring I was
> > talking about in my previous mails. Please let me
> > know, if this change is
> > acceptable for you. If it is, I will finish it
> > afterwards.
> >

Reply via email to