Glen, 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 situation.
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]> To: <[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. > > > >
