RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] Jeremias Maerki wrote: Hi guys, (Just catching up on the postings of the last few days, this one caught my eye...) although I'm still a bit concerned that you based your PDF part on the maintenance branch code (that's still the case, isn't it?). FOrayPDF is based on the maintenance branch code, but I am not sure I understand your point. Victor, IIC, Jeremias' concern is about the PDF lib in HEAD containing substantial improvements over the code in the maintenance branch. One aspect that springs to mind is WRT encryption support --as I recall, maintenance still had some problems with this, for instance, when using custom fonts... Jeremias once mentioned that, in order to make it work properly, he had to make significant changes to the PDF-related code. Greetz, Andreas
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Andreas L. Delmelle wrote: Victor, IIC, Jeremias' concern is about the PDF lib in HEAD containing substantial improvements over the code in the maintenance branch. One aspect that springs to mind is WRT encryption support --as I recall, maintenance still had some problems with this, for instance, when using custom fonts... Jeremias once mentioned that, in order to make it work properly, he had to make significant changes to the PDF-related code. Yes, I am well aware that there are improvements to HEAD in several places, and that FOray will be missing those for the moment. I fully intend to eventually integrate the HEAD improvements into FOray, but 1) it is non-trivial, 2) I have bigger issues ATM (still trying to get FOTree isolated), and 3) I don't want to do much until I either have to, or until FOP decides how it will proceed -- if FOP decides to start with FOray's isolation work and upgrade to HEAD, then it might be a joint effort. If FOP decides to isolate HEAD's PDF lib directly, and if they use a common interface (like aXSL), then I shouldn't duplicate that effort in FOray, I should just wait until FOP is done with that work and drop it into FOray. If FOP doesn't want PDF isolated, or has no interest in using a common interface, then I'm not part of the picture at all. My main point to Jeremias is that none of this has anything to do with building an interface that everyone can use, except that: 1) FOray already has the interface at least partially designed by virtue of isolating the PDF code, and 2) making an interface *before* starting isolation work is a big help in that work. Victor Mote
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Jeremias Maerki wrote: from the website I don't quite get the scope of the project. That might have to be made clearer. Anyway, I didn't want to Yes, just as soon as it is totally clear to me :-) Right now, it boils down to here are some things that I think could/should be shared, can anybody think of anything else? talk about it just yet, because it's not ready, but recently I started writing a JAXP-like API for XSL-FO processors (I called in JAFOP for now). It basically implements the ideas we came up with in the API discussion over a year ago. In the next few months I will probably need to integrate several different FO-processors and want to have a common API for all. Especially having a uniform API between FOP maintenance branch and HEAD is important to me because I need to get FOP 0.20.5 set up for PDF output and I will most probably need the RTF output of FOP HEAD quite soon (all in the same VM, of course). Also, the fact that we got 4 OS-FO-processors screams for a common API so they can be used interchangeably. I think you are thinking API for the application as a whole. My vision for aXSL goes quite a bit deeper than that, trying to get a common API for the modules, IOW breaking the problem down into smaller pieces. My perfect world right now would have me using FOrayFont with RenderX. (That is not to say that FOrayFont is as good as RenderX's font handling -- it is not, yet anyway. But it means that I can get where I need to go more quickly with FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to aXSL, making FOray do so would seem to make it more usable to more people. And it at least gives hope to someone writing a piece that it might be pluggable with some other pieces. There was a thread several weeks ago that had to do with how to standardize extensions between the various applications, and Finn's work on Property binding was an indirect influence here as well. However, the main thing that started me down this path was thinking through the possibility of further modularization within FOray. Right now, for example, FOrayFont is totally independent of anything that looks like XSL-FO processing. But FOrayPDF is highly dependent on FOrayFont as are layout, the renderers, etc. It seemed like a desirable thing to pull out a layer of abstraction that lets FOrayPDF work, for example, with any other conformant Font system, or vice versa. Now, fonts and graphics are pretty easy. I can pull out an abstraction for fonts that has three interfaces, one of which is already written (it may need to get more complex later), and probably do a similar thing with graphics. FOTree is much more complex, and AreaTree has complexities for a different reason. Can it be that we had the same idea at the same time again? :-) Of course, having standardized validation messages and such goes a bit beyond what I imagined, but that's ok. Actually, I don't envision standardized validation messages, although that would be OK. (I suppose you could even handle the multi-lingual aspects of that in a nice way.) I think that the original thread was dealing with how the exceptions should be thrown, and that *would* be a good thing to standardize, but different applications might want to handle them differently. I would characterize the two ideas as different, but very compatible, and thinking along the same general lines. What you have done with JAFOP could easily be a part of aXSL (or vice versa), and I would be glad to have you participate, when the appropriate time comes. Victor Mote
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Ah, now I'm starting to see where this is going. I think this something extremely difficult to do. To a certain degree it sounds like my ideas/plans for the XML Graphics project, namely to separate certain peripheral components (fonts, PDF lib, Graphics2D implementations etc.) from FOP so efforts can be pooled between projects where easily possible (i.e. without major religious wars). For example, Peter is quite interested in the Graphics2D implementations. But going to a level of detail you hint at (at least that's my impression) will prove really difficult. You know I'm all for componentization, but you may have too high hopes here. But I could be wrong. Don't spend too much time explaining this to me. :-) We'll just see what happens. I will monitor what's going on. So, we're still going in the same general direction although I'm still a bit concerned that you based your PDF part on the maintenance branch code (that's still the case, isn't it?). Concerning the common end-user API, I'll publish my findings as soon as they are somewhat presentable. Jeremias Maerki
RE: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Jeremias Maerki wrote: Ah, now I'm starting to see where this is going. I think this something extremely difficult to do. To a certain degree it Agreed. sounds like my ideas/plans for the XML Graphics project, namely to separate certain peripheral components (fonts, PDF lib, Graphics2D implementations etc.) from FOP so efforts can be pooled between projects where easily possible (i.e. without major religious wars). For example, Peter is quite interested in the Graphics2D implementations. But going to a level of detail you hint at (at least that's my impression) will prove really difficult. You know I'm all for componentization, but you may have too high hopes here. But I could be wrong. Don't spend too much time explaining this to me. :-) We'll just see what happens. I will monitor what's The standards themselves do not need to be monolithic. So maybe one implementation implements only aXSL-Font (I'm making this up as I go), while another might implement all of them. The idea is that one more axis of benefit is added into the product mix. Assume that modularization is even possible, which is yet to be proved, at least by any of the open-source implementations of which I am aware. Assume also that, all other things being equal, it is a desirable trait, not just for the developer, but for the end user. If these are both true (and I think they are), a product that chooses *not* to implement it would presumably want to have a really good reason for not doing so. Defoe's reason might be superior performance (as I understand it), which is quite possible, and FOP's might be a quicker time-to-market (as I understand it), also quite possible, at least starting from today. If *setting* a standard devolves into a religious war, we should probably abandon the effort. However, I don't know that it needs to. When you think about it an API for the FOTree, for example, the standard almost writes it for you. going on. So, we're still going in the same general direction although I'm still a bit concerned that you based your PDF part on the maintenance branch code (that's still the case, isn't it?). FOrayPDF is based on the maintenance branch code, but I am not sure I understand your point. I assume you are thinking of how to get a PDF-library created in the new Graphics project? If I understand where you are headed, you have to either duplicate in HEAD the work that I have done in isolating it, or you have to duplicate the changes made since FOP forked itself. Since it is in FOray's interest to have the better PDF library available, I might do the latter -- it is just a matter of priorities right now finishing the modularization is more important (to me). And since PDF is a relatively discrete part of the system, it may not be too hard to do. If you guys decide to do the former, having the aXSL APIs in place would be a very valuable tool in that process. I'll be glad to explain why when you are ready to look at it, and perhaps I'll have something concrete (about the abstractions :-) to show you by then as well. I'll be very happy to try to coordinate this stuff so that we don't duplicate effort -- there has been and will be too much of that as it is. Victor Mote
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
AreaFactory patch (once again ;-)
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. The generic Area create(FObj, LayoutManager) method was left in the interface to, although its usage in client code is not recommended. - ATM, all the create method have the same argument signature. I think, that this is a place which can undergo changes in future (TextArea creation is a good example). This will be dependent on the amount of work which might be shifted from LMs to AreaFactories... 2) org.apache.fop.area.DefaultAreaFactory - basic implementation; in most cases just default constructor of an area subtype is called 3) FOUserAgent - getAreaFactory()/setAreaFactory() method pair - same as in the example sent before 4) AbstractLayoutManager - I added convenience method getAreaFactory() to this class. So the actual area creation in LMs is usually limited to: curBlockArea = getAreaFactory().createBlock(fobj, this); 5) Default constructors - I changed several Area classes, too. In particular those which have not had a default constructor, yet. So, that's it. Thanks to those who have supported this refactoring. It's in the bugzilla now, so it's up to you what you will do with it. Anyway, please send me any comment you have. I don't say that this is a finished and non-changeable piece of code (such things don't exists in SW development, do they? ;) any further suggestions/correction i am going to implement. Greets, Tibor Vyletel ICQ# 79458455
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
aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor Mote
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
I am impressed by your seemingly boundless dedication to XSL and its related fields. Glen --- Victor Mote [EMAIL PROTECTED] wrote: I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it.
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Victor, Thanks, I'll keep an eye on it. I'll drop by the forum as soon as I get a chance. (Busy with Defoe atm) Peter
Re: aXSL (Was: RE: Exceptions. (Was: AreaFactory patch))
Victor, from the website I don't quite get the scope of the project. That might have to be made clearer. Anyway, I didn't want to talk about it just yet, because it's not ready, but recently I started writing a JAXP-like API for XSL-FO processors (I called in JAFOP for now). It basically implements the ideas we came up with in the API discussion over a year ago. In the next few months I will probably need to integrate several different FO-processors and want to have a common API for all. Especially having a uniform API between FOP maintenance branch and HEAD is important to me because I need to get FOP 0.20.5 set up for PDF output and I will most probably need the RTF output of FOP HEAD quite soon (all in the same VM, of course). Also, the fact that we got 4 OS-FO-processors screams for a common API so they can be used interchangeably. Can it be that we had the same idea at the same time again? :-) Of course, having standardized validation messages and such goes a bit beyond what I imagined, but that's ok. On 04.11.2004 22:58:39 Victor Mote wrote: Finn Bock wrote: Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is already taken, but at the time I registered the axsl.org domain, and I finally went ahead yesterday and opened up a SourceForge project for it. There isn't much content there now, and I doubt that anyone wants to spend much time on it ATM, but we have a place to talk about such things for those who are interested -- I think Joerg at least will appreciate it being somewhere else, and I know there are others who are not interested as well. It deals with more than just parsing and exceptions, but those are (or could be) parts of it. Here is the website: www.aXSL.org If FOP is interested, you are welcome to send a delegate, who will automatically become a committer. Also, Peter West is welcome to be a committer -- if we can accommodate his design, we'll sure try. I'll eventually invite the commercial developers too, if it looks like there is anything here that helps. Jeremias Maerki
Re: AreaFactory patch
Andreas L. Delmelle wrote:
snip/
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.
snip/
Chris
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: Exceptions (was: AreaFactory patch)
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Would anyone expect that Defoe would subclass SAXException for document validation errors? If not (it doesn't), why not? Yes, if you use a SAX parser, why not? My point is that at the top-level, no SAXExceptions should be thrown (or a subclass from SAXException) since these could be caught by a higher-level catch-block for SAXExceptions, leading to all sorts of unpleasant surprises or incomprehensible error messages. Could be that the Exception really has its roots in the SAX parser, but FOP/Defoe isn't purely about SAX --FOP just happens to use SAX to parse the XML. There's also at least layout and rendering where errors can occur (esp. if we strive for pluggable layoutmanagers or renderers --could easily lead to misconfigurations that might surface only when the app actually tries to layout/render something, so when the XML parsing is already well under way...) What FOP or Defoe does within the context of their own packag(es) doesn't really matter so long as it's properly documented in the JavaDocs, but for an end-user --whether command-line or embedded-- the error should IMO definitely indicate that the error comes from within FOP/Defoe, which is not the case when you just hand off a SAXException or one of its subclasses. (Same goes for FileNotFoundExceptions... Very tempting to use this for all cases where 'a file cannot be found', but in case we use it in FOP, it should come out wrapped in a FOPException --XSL processors would also report this as i.e. a TransformerException, caused by a lower-level FNFE. Users who know their way in Java would associate an FNFE with particular types of classes and operations that clearly indicate that a reference to a File is created. With FOP or Defoe the creation of these file-references is shielded from the end-users, so it would turn out to be confusing to throw FNFEs at them...) 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? Very, very good point indeed! The answer, of course, is no. Should IMO be at least a form of DOMException. Greetz, 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
-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. snip / 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... snip / 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
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
--- 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=10913138836r=1w=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
-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 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
[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
Glen Mazza wrote: snip/ 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
-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.)
snip /
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
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
Exceptions. (Was: AreaFactory patch)
[Peter] 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? That is your choice. Surely exceptions that occured during SAX event handling (eg startElement) should be handled, either by wrapping the exception in a SAXException, or by passing SAXExeption subclasses along or by throwing some kind of RuntimeException (did I miss another option?). I don't think exception handling by e.printStackTrace(); is a long term solution. If not (it doesn't), why not? AFAIK, there is no well defined API to XSL:FO parsing, so everybody will do it differently. 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? Ofcourse not. 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. Do you mean that the 3 different processors should ideally report the same validation errors in the same manner? That can only happen after someone standardize a SAFO API (Simple API for FO parsing). Until then all implementation will throw different exceptions, which is fine by me. (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. True, but FOP heavily depends on SAX. regards, finn
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
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
-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
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
AreaFactory patch
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. Change description: 1) new interface: org.apache.fop.area.AreaFactory default implementation: org.apache.fop.area.DefaultAreaFactory - new definition how new areas should be created and accessed. 2) FOUserAgent - addition of setAreaFactory(AreaFactory) AreaFactory getAreaFactor() methods - configuration for new feature 3) LayoutManagers - in several managers (in fact, in those I had had my private code) area instantiation was changed to proposed factory pattern. Best regards, Tibor Vyletel ICQ# 79458455 AreaFactoryPhase1.patch Description: Binary data
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.
