Re: AreaFactory patch (once again ;-)
--- Tibor Vyletel <[EMAIL PROTECTED]> wrote: > Hello fopsters, > > so I have finished (and published in bugzilla) the > patch which have aroused > quite a discussion around here. > > Just a short description: > 1) org.apache.fop.area.AreaFactory > - now contains specific create method for each > (used) subclass of Area. I like the results of this change in particular. Glen
Tibor's AreaFactory patch (Re: AreaFactory patch)
--- Finn Bock <[EMAIL PROTECTED]> wrote: > > I only see a need for plugable LMs, but the > AreaFactory patch is so > small that I see no problem with throwing a bone to > Tibor. > > regards, > finn > OK, that opinion was what I was trying to get at. Someone else to second Andreas' feelings on the issue. Tibor, you may wish to try again with a Bugzilla patch but incorporate Finn's two suggestions. Also, you were completely correct as to the purpose of FOUserAgent, so if you can have the getAreaFactory() implemented somewhere else outside of that class (LM package, perhaps, or other places) that would a good idea. (FOUserAgent.*set*AreaFactory() is still fine.) Please place it in Bugzilla, and we can have the rest of the team comment on it. I see nothing vetoable myself, so it will be on how others feel. No guarantees, but hopefully another team member (Andreas?) will apply it for you. I, however, will be taking myself out of this issue. If however, you're really fine with just Pluggable LM's, another option is to modify Finn's patch on the issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30500 It's a bit out of date due to other changes in the code (namely, I moved layout code out of the former AddLMVisitor and into new LM classes after this patch was done.) But that would also be helpful for others. Thanks, Glen
Re: AreaFactory patch
[Glen] Finn, keep in mind--both you and Simon wanted pluggable LM's, and you even supplied a patch for it a few months ago. But you have been mostly silent on the matter ever since (i.e., it looks like you don't have a need for it ATM.) Or perhaps I've been working on other things, like property optimizations and exceptions. And just maybe I didn't feel that I had to be the one who implemented plugable LMs since I wasn't the one who removed the existing plugability. So sometimes it is good to have things sit in Bugzilla for a couple of months, see if others want it, or what modifications they want, or see if even the original requestor still needs it. Also, Tybor seemed to be fine with using pluggable LM's instead of pluggable Area's--i.e., not even needing them *now*--which would make his desires in sync with yours and Simon's (and mine), as well as keep our layout code in our LM's instead of moving to the Area objects. Do you still see a need then for *both* pluggable LM's and pluggable Areas in our code then? I didn't find that realistic, as I am uncertain of the additional power that it offers, but am asking your opinion here. I only see a need for plugable LMs, but the AreaFactory patch is so small that I see no problem with throwing a bone to Tibor. regards, finn
Re: AreaFactory patch
Andreas L. Delmelle schrieb: -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] I disagree with you that FOP should have ceased all development during the four or five months you were off the list. Open-source doesn't work that way. Hmmm... One question: Are you so bent on misinterpreting one's statements? Do you do it on purpose? :-) I have nowhere indicated anything of the above --on the contrary, I have even clearly pointed out it was a personal matter. Personal matter or not, this was the logical conclusion of your complaint about code changes to AddLMVisitor occurring during the several months you were gone. Glen
RE: AreaFactory patch
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > I disagree with you that FOP should have ceased all > development during the four or five months you were > off the list. Open-source doesn't work that way. Hmmm... One question: Are you so bent on misinterpreting one's statements? Do you do it on purpose? :-) I have nowhere indicated anything of the above --on the contrary, I have even clearly pointed out it was a personal matter. You're reading too much in what I wrote. Greetz, Andreas
RE: AreaFactory patch
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > To be completely honest, I was a bit disappointed > when after a couple of > months absence, finally able to check out the > sources again, I had to find > that the whole Visitor design just got kicked out Andreas, we thoroughly discussed the issue for more than a week [1] and you were more than welcome to take part in the discussion. You opted not to. [1] http://marc.theaimsgroup.com/?t=10913138836&r=1&w=2 > --before I even had a > chance to study it more closely... You were completely silent for several months, a period several score times long enough for you to "study it more closely" were you so inclined...Again, you could have checked in with an email or two during the period. I disagree with you that FOP should have ceased all development during the four or five months you were off the list. Open-source doesn't work that way. Glen
RE: AreaFactory patch
Andreas L. Delmelle wrote: > Not only that. The use-case he described doesn't seem at all > far-fetched. > Imagine FOP/FOray/Defoe having an AWT renderer that displays > an editable XSL-FO in one window, the rendered result in the > other, and allows for updates/modifications made in the first > to be --as fast as reasonably > possible-- reflected in the rendered version, without having > to render the whole --possibly very large-- document anew > every time. Those who are not at least a little curious about > this, may now leave :-) Yes. You might be interested in: http://www.foray.org/goals.html#big Victor Mote
RE: AreaFactory patch
> -Original Message- > From: Victor Mote [mailto:[EMAIL PROTECTED] > Hi Victor, > I know better than to take this bait, but ... > No matter... +1 for starters > It has already been pointed out that, if the Visitor stuff was so > terribly complex, there were other solutions that could be applied that > didn't sacrifice modularity. To be completely honest, I was a bit disappointed when after a couple of months absence, finally able to check out the sources again, I had to find that the whole Visitor design just got kicked out --before I even had a chance to study it more closely... but that's personal, of course. I didn't understand enough of it to see its particular (dis)advantages. All I want to say: it happens often enough --and not only in SW-development-- that ideas or proposals get turned down because those concerned with the approval don't understand it and/or don't want to make any effort to grasp it. Logic a la: "Nah, looks too difficult to *me*. Let *us* not do that." > 3. Things should be made as simple as they can be, and no simpler. More > importantly, there are tradeoffs even within simplicity. > Modularization is one aspect of simplicity. I concur, and as an addition IMO, lately, it seems as if development is focused on 'too much simplicity' --the desire to make FOP work with only a minimum number of classes/interfaces, 'just one' class being ideal from that viewpoint. Fact remains that with all the tasks we want FOP to perform, source code is *never* going to be 'easy-to-follow'. It will always take time before one is able to trace the flow of execution and actually 'see' it at work in the source. Tibor seemed to understand it well enough, so I decided to back his proposal... > > So here is a promising developer that shows up with an idea. > It helps him get his work done, and seems to make for a > cleaner design (I haven't looked at it closely, but I haven't heard > anybody argue with this). Not only that. The use-case he described doesn't seem at all far-fetched. Imagine FOP/FOray/Defoe having an AWT renderer that displays an editable XSL-FO in one window, the rendered result in the other, and allows for updates/modifications made in the first to be --as fast as reasonably possible-- reflected in the rendered version, without having to render the whole --possibly very large-- document anew every time. Those who are not at least a little curious about this, may now leave :-) Cheers, Andreas
RE: AreaFactory patch
Glen Mazza wrote: > I've bought it due to my work with the apps package and > removing AddLMVisitor, and how reducing the complexity > allowed many other changes in other areas that weren't > previously apparent to occur. I also think that many of your > later enhancements in properties wouldn't have become obvious > if you didn't first get us out of the XSLT-generated > properties classes. Even I was able to implement some > (minor) property-related API changes as a result of your work > in getting rid of the autogenerated code. I know better than to take this bait, but ... 1. The XSLT-generated stuff is a separate issue. Not relevant here at all. 2. It has already been pointed out that, if the Visitor stuff was so terribly complex, there were other solutions that could be applied that didn't sacrifice modularity. Also, it was never intended as a long-term solution, but rather reflected the current state of the layout design, which, after modularization, would have (or could have) changed. 3. Things should be made as simple as they can be, and no simpler. More importantly, there are tradeoffs even within simplicity. Modularization is one aspect of simplicity. It is true that modularization requires the use of interfaces, which add some incremental complexity. But the benefits of having good interfaces and clean separation of concerns reduce complexity much more on a different axis. I have said before that I am glad that Xalan is a separate module from FOP -- that was good thinking. I'm glad that FOP doesn't have to compute disk sectors or lay out pixels on a page -- somebody was smart enough to abstract out operating systems and printer drivers instead. Now, some on this list persist in the "let's finish coding the project and then we'll stop and design it" line of argument. I have taken it as a settled issue that this is FOP's policy, hence FOray. I won't work on a project that takes that attitude. I unwittingly tried that for about 18 months, lost a year of my life and an incalculable amount of money in both real and opportunity costs. FOP lost a good (IMO) developer and managed to create for itself unnecessary and wasteful competition where none was really needed. What a waste. So here is a promising developer that shows up with an idea. It helps him get his work done, and seems to make for a cleaner design (I haven't looked at it closely, but I haven't heard anybody argue with this). You can tell him (like you did me) "we don't need no steeenking clean design." Or you can learn a lesson and try to start developing relationships with the kind of developers that you are going to need to finish this project. Makes no difference to me. But, please, if you choose the former, send that promising developer toward FOray -- I'm almost at the stage where I can drop in the new layout system there. We'll find a place for good design ideas there. Victor Mote
Re: AreaFactory patch
--- Finn Bock <[EMAIL PROTECTED]> wrote: > [Chris] > > >>I'm definitely in agreement with you on this one > Glen. Lets keep > >>Layout simple whilst its still unfinished. > >>Pluggable LMs can be added once we have an > >>initial release. > > [Andreas] > > > Well... (sigh)... well ('nutha sigh) > > > > What *does* Finn think, in that case? So far, I've > yet to hear a single > > *solid* argument pleading against the proposed > change. Of course, something > > like LM Makers can be added later on --the > proposed AreaFactory shouldn't > > hinder that. > > I got some minor suggestions to the patch: > > - It should be strict typed: createBlock(..), > createInline(..) > - It should be complete so that all area creation > was done through the >factory, not just the 3 areas that Tibor needs. > Finn, keep in mind--both you and Simon wanted pluggable LM's, and you even supplied a patch for it a few months ago. But you have been mostly silent on the matter ever since (i.e., it looks like you don't have a need for it ATM.) So sometimes it is good to have things sit in Bugzilla for a couple of months, see if others want it, or what modifications they want, or see if even the original requestor still needs it. Also, Tybor seemed to be fine with using pluggable LM's instead of pluggable Area's--i.e., not even needing them *now*--which would make his desires in sync with yours and Simon's (and mine), as well as keep our layout code in our LM's instead of moving to the Area objects. Do you still see a need then for *both* pluggable LM's and pluggable Areas in our code then? I didn't find that realistic, as I am uncertain of the additional power that it offers, but am asking your opinion here. > > I've never bought the increased complexity argument. > Not in this case > and not in any of the previous cases where it was > raised. > I've bought it due to my work with the apps package and removing AddLMVisitor, and how reducing the complexity allowed many other changes in other areas that weren't previously apparent to occur. I also think that many of your later enhancements in properties wouldn't have become obvious if you didn't first get us out of the XSLT-generated properties classes. Even I was able to implement some (minor) property-related API changes as a result of your work in getting rid of the autogenerated code. Glen
RE: AreaFactory patch
Finn Bock wrote: > I got some minor suggestions to the patch: > > - It should be strict typed: createBlock(..), createInline(..) > - It should be complete so that all area creation was done through the >factory, not just the 3 areas that Tibor needs. Yes. Victor Mote
Re: AreaFactory patch
Andreas L. Delmelle wrote: Hi fellas, Well... (sigh)... well ('nutha sigh) What *does* Finn think, in that case? So far, I've yet to hear a single *solid* argument pleading against the proposed change. Of course, something like LM Makers can be added later on --the proposed AreaFactory shouldn't hinder that. All we heard up to here is a few vague concerns about so-called increased complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern for chrissake! It doesn't bite... or does it? Anyone? Well, Im not trying to start a fire fight here. And its true that the requested change is a simple Factory pattern. I agree the concept is simple. But what I object to is people keep adding loads of pluggable this and pluggable that to a system whose basics arent yet finished. So all I am trying to say is lets hold off on pluggable interface A, B and C, until the basics are finished. I dont think this is a vague arguement. It may also be worthwhile stepping back from implementations here and consider what are the business reasons for adding the pluggable LMs? Just because a newbie on the list says he needs them, he doesnt say why, we have just accepted that maybe he does. I think we should ask what the business usecase is? Is it related to XSL-FO in anyway, we dont know. If theres a good business case, then I wont object. But so far, no business requirements have been stated. Chris
Re: AreaFactory patch
[Chris] I'm definitely in agreement with you on this one Glen. Lets keep Layout simple whilst its still unfinished. Pluggable LMs can be added once we have an initial release. [Andreas] Well... (sigh)... well ('nutha sigh) What *does* Finn think, in that case? So far, I've yet to hear a single *solid* argument pleading against the proposed change. Of course, something like LM Makers can be added later on --the proposed AreaFactory shouldn't hinder that. I got some minor suggestions to the patch: - It should be strict typed: createBlock(..), createInline(..) - It should be complete so that all area creation was done through the factory, not just the 3 areas that Tibor needs. All we heard up to here is a few vague concerns about so-called increased complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern for chrissake! It doesn't bite... or does it? Anyone? I've never bought the increased complexity argument. Not in this case and not in any of the previous cases where it was raised. regards, finn
Re: AreaFactory patch
Andreas L. Delmelle wrote: All right, all right, maybe I'll just 'agree to disagree' in this case ;-) --mind you, *not* WRT to Exceptions, though... I declined to further the debate, but I'd much rather see GM read Sun's APIDoc for java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that FOP has no business throwing an 'IllegalArgumentException' or a 'FileNotFoundException', no matter how well the name seems to fit the error... (esp. the first, since it subclasses RuntimeException = unchecked) [*] On the topic of exceptions, and now that it's all over... I was puzzled by this discussion. Would anyone expect that Defoe would subclass SAXException for document validation errors? If not (it doesn't), why not? And if someone was inclined to write an FO processor using a DOM front-end, would you expect validation errors to throw subclasses of SAXException? The same fo file, with the same errors, could be processed by three different processors, using three different parsing methodologies, and the same validation errors would encountered. (OK, you can classify at least two categories of validation error, but I think the argument still applies.) SAX != XML parsing, let alone document validation. Peter
RE: AreaFactory patch
> -Original Message- > From: Chris Bowditch [mailto:[EMAIL PROTECTED] > > Glen Mazza wrote: > > > 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.) > I'm definitely in agreement with you on this one Glen. Lets keep > Layout simple whilst its still unfinished. > Pluggable LMs can be added once we have an > initial release. Hi fellas, Well... (sigh)... well ('nutha sigh) What *does* Finn think, in that case? So far, I've yet to hear a single *solid* argument pleading against the proposed change. Of course, something like LM Makers can be added later on --the proposed AreaFactory shouldn't hinder that. All we heard up to here is a few vague concerns about so-called increased complexity. What?!? It's a plain, simple, basic-as-can-be Factory pattern for chrissake! It doesn't bite... or does it? Anyone? All right, all right, maybe I'll just 'agree to disagree' in this case ;-) --mind you, *not* WRT to Exceptions, though... I declined to further the debate, but I'd much rather see GM read Sun's APIDoc for java.lang.Throwable --makes sense, no? Enough, maybe, to convince one that FOP has no business throwing an 'IllegalArgumentException' or a 'FileNotFoundException', no matter how well the name seems to fit the error... (esp. the first, since it subclasses RuntimeException = unchecked) [*] So, Tibor, can you post your patch on Bugzilla? Fine by me to leave all as it is now... and maybe when the time is ripe, we'll use it. Thanks very much for the contribution. I just hope this piece of sound logic doesn't go to waste. Greetz, Andreas [*] as a slightly more realistic example: try { ... someObject.processFile(); ... fop.run(); ... } catch( FNFE e ) { // this will catch FNFEs regardless of which // of the two objects it gets thrown by. // sorting out which one here can prove to be // quite messy and painful... // now, if only one of the two was 'behaving'... }
Re: AreaFactory patch
Glen Mazza wrote: 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. I'm definitely in agreement with you on this one Glen. Lets keep Layout simple whilst its still unfinished. Pluggable LMs can be added once we have an initial release. Chris
Re: AreaFactory patch
Hello, - Original Message - From: "Andreas L. Delmelle" <[EMAIL PROTECTED]> > > Hi, > > > 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. > > > > Just let me see if I get this straight... > The only real change that is being proposed, is delegating the creation of > Areas to a Factory which is an instance variable in the UserAgent, where > currently the instantiations happen directly in the LMs (new ...)? Correct? > And all that leads to being able to plug in custom Area Factories? > Yes, that's all. Very similar situation would take place in case of pluggable LMs. > Complexity of design doesn't increase very much... (well, it certainly > doesn't 'shoot through the roof' :-) ) > > To address Glen's concern about changing: > > curBlockArea = new Block(); > > into > > curBlockArea = (Block) fobj.getUserAgent(). >getAreaFactory().create(Block.class, fobj, this); > > Couldn't we, say, add a method to the UserAgent that contains the > communication with the AreaFactory, so that the above would become: > > curBlockArea = (Block) fobj.getUserAgent().createArea(Block.class, fobj, > this) > > The method in the UserAgent would simply be: > > Area UserAgent.createArea(...) { > return getAreaFactory.create(...); > } > > Or maybe even add one to the fobj itself, so that in the LMs the code would > be: > > curBlockArea = (Block) fobj.createArea(Block.class, this) > > In combination with the above, the method in FObj would look like: > > Area FObj.createArea(class, LM) { > return getUserAgent().createArea(class, this, LM); > } > > Adding the possibility for the FObj to intervene, manipulate the Area before > returning it from the UA to the LM... (--usefulness?) > Dunno, maybe the logic of 'creating/instantiating' the Areas should indeed > be moved away from the LMs --restrict the task of the LM to merely 'laying > out the content on' the Areas as supplied, in this case, by the UserAgent... > > Actually, doesn't seem like such a bad idea to me, but I'd definitely like > to hear some other opinions. > > > Cheers, > > Andreas I don't like decreased readabality of more complicated code for Area creation, too. But: 1) createArea(...) in UserAgent: In my opinion, UserAgent is more a place which provides configuration details for other elements in XSL-FO processing (layouter, renderer, ...), creation of areas (although only delegated to actual AreaFactory) is not a concern of this class 2) createArea(..) in FObj: FObj tree is a data structure independent of the layout; layout phase uses FObjs to get properties and content from them to calculate visual representation. Polluting FObj with link to LayoutManager and Area classes would create a circular reference between FO Tree and Layout phases and unnecessary coupling between them would be introduced. So if the goal is to increase the aesthetics of code which creates area objects in LM, the right place is LM itself: Area LayoutManager.createArea(Class, FObj) { return FObj.getUserAgent().getAreaFactory().create(Class, FObj, this); } and then: curBlockArea = (Block)createArea(Block.class, fobj); Best regards, Tibor Vyletel ICQ# 79458455
RE: AreaFactory patch
> -Original Message- > From: Tibor Vyletel [mailto:[EMAIL PROTECTED] > Hi, > 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. > Just let me see if I get this straight... The only real change that is being proposed, is delegating the creation of Areas to a Factory which is an instance variable in the UserAgent, where currently the instantiations happen directly in the LMs (new ...)? Correct? And all that leads to being able to plug in custom Area Factories? Complexity of design doesn't increase very much... (well, it certainly doesn't 'shoot through the roof' :-) ) To address Glen's concern about changing: curBlockArea = new Block(); into curBlockArea = (Block) fobj.getUserAgent(). getAreaFactory().create(Block.class, fobj, this); Couldn't we, say, add a method to the UserAgent that contains the communication with the AreaFactory, so that the above would become: curBlockArea = (Block) fobj.getUserAgent().createArea(Block.class, fobj, this) The method in the UserAgent would simply be: Area UserAgent.createArea(...) { return getAreaFactory.create(...); } Or maybe even add one to the fobj itself, so that in the LMs the code would be: curBlockArea = (Block) fobj.createArea(Block.class, this) In combination with the above, the method in FObj would look like: Area FObj.createArea(class, LM) { return getUserAgent().createArea(class, this, LM); } Adding the possibility for the FObj to intervene, manipulate the Area before returning it from the UA to the LM... (--usefulness?) Dunno, maybe the logic of 'creating/instantiating' the Areas should indeed be moved away from the LMs --restrict the task of the LM to merely 'laying out the content on' the Areas as supplied, in this case, by the UserAgent... Actually, doesn't seem like such a bad idea to me, but I'd definitely like to hear some other opinions. Cheers, Andreas
Re: AreaFactory patch
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. > > > >
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. >