RE: [VOTE] Re: LayoutStrategy
Victor Mote wrote: Because we are such a small group, I am hoping to get unanimity on all of the points. If I have addressed your concerns with the above clarifications, please consider changing the -1 votes to a zero (or better). If anybody has serious reservations, I need to think about doing this in a local fork instead of in the repository. Obviously, I'd like to avoid that. Hmmm. I'm not sure how to interpret the silence. I'm going to press on with my proposals unless I get some sort of substantive reply. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Re: LayoutStrategy
--- Victor Mote [EMAIL PROTECTED] wrote: Hmmm. I'm not sure how to interpret the silence. I'm going to press on with my proposals unless I get some sort of substantive reply. Victor Mote Victor, I apologize for the silence--I did read your email on Sunday and more thoroughly yesterday. I was planning on adding more to what you wrote tomorrow--I've been too busy and/or worn out this week to give a useful response to your proposals. But let me try now: 1.) BTW, I was happy with your explanations to my concerns I raised while voting--in particular your assurances that Control will not be getting too much into each of the classes. We seemed to share many of the same concerns. 2.) In general, much of the system I am not versed in yet, so I don't want to stop you with your redesign ideas--however, I do expect Jeremias, Joerg, and Peter to open up their mouths when they see something going wrong. However, for me, I can't beat a plan with no plan, so I'm not going to slow things down by trying. 3.) Offhand, working on my own, (and before realizing that I need to change a lot of what I did because of my mistakes with the parsers, as well as overlooking several other things), I was able to get rid of the Driver class entirely, as well as the Starter classes. The cost was only a slightly expanded apps.Fop class (200 lines) and a larger (600-700 line) FOTreeBuilder. Due to the large handshaking between FOTreeBuilder and Driver, I also found that adding some code to the former usually allowed me to remove much more code from the latter. All in all, it seems to be pretty code-efficient. 4.) I'm aware of your horrors of letting an FOTreeBuilder know the render type, etc. I agree with you now on that. My thinking now is to switch to a new fo.XSLFOProcessor class which includes, as a child class, the full definition of a fo.XSLFOProcessor.FOTreeBuilder class. Within fo.XSLFOProcessor but outside of its FOTreeBuilder definition, is much the same control-type code currently in Driver (renderer information, etc.) This way we still get the lines of code efficiency without breaking so much the OO design in terms of letting FOTreeBuilder know about everything. What would be in the apps package if we had such a XSLFOProcessor class? Hopefully, just something simple like this in apps.Fop: XSLFOProcessor xslfoProcessor = new XSLFOProcessor(); bos = new BufferedOutputStream(new FileOutputStream(options.getOutputFile())); xslfoProcessor.setOutputStream(bos); xslfoProcessor.setInputHandler(inputHandler); xslfoProcessor.run(); bos.close(); System.exit(0); Ideally, that would be mostly it. My current design-thinking is that once flow of control leaves the apps package, it does not return until has a full document finished. 5.) The drawbacks, however, of what I'm mentioning above is that your Control is taking care of a lot more than just tree building--layout, rending, area tree, etc. Again, though, I don't know much about those areas yet to comment constructively on them--so I'm reluctant to stop your full solution just because I may have different ideas on the first 20%. In general, I would then +1 you going ahead with your design--providing J, J P are not shy in opening up their mouths when needed (I certainly won't be! ;)-- If and when it proves more code efficient to place certain parts of Control in different packages, we can look at doing so later. Thanks, Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Re: LayoutStrategy
Glen Mazza wrote: Ideally, that would be mostly it. My current design-thinking is that once flow of control leaves the apps package, it does not return until has a full document finished. I think we are on the same page here, or at least I see no conflict. I don't think of the control classes as being part of apps. apps would be one of several ways to instantiate and access control. The only reason I want to put anything in Driver is that it *is* control for now. Please, *please* feel free to refactor the stuff I put in there to better places as you see fit. I was hoping to get that straightened out before starting the Layout Strategy stuff, but I think you and Jeremias will do The Right Thing as you move forward. In general, I would then +1 you going ahead with your design--providing J, J P are not shy in opening up their mouths when needed (I certainly won't be! ;)-- If and when it proves more code efficient to place certain parts of Control in different packages, we can look at doing so later. I'm counting on getting corrected if I need it. And I definitely don't want this stuff to live in Driver forever. I just don't see the big Avalonized picture yet, and probably won't until it is close to complete. Thanks for the response. BTW, I really didn't mean to press you for the response -- I just thought I had better get moving. I am very eager to at least test the idea of getting the main branch working again so that we can start fixing fonts, graphics, FO tree, etc. in one place. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: LayoutStrategy
On 21.07.2003 16:48:30 Victor Mote wrote: Fellow FOP developers: The thread I have most been wanting to work on (and that which I think is most important to this project right now) is that of cleaning up the lines between our various modules, and getting LayoutStrategy working, so that we can try to integrate our one working LayoutStrategy (from maintenance branch) into the trunk code. I have felt blocked on that thread until we get the API and control structure fixed a bit. I woke up this morning realizing that perhaps we can make some progress here anyway, but this definitely requires a consensus. Please withhold judgment on the earlier items until you see the whole picture of where I am headed. Here is what I propose : It is still a mystery to me how you will port the old layout over but if you see a way then go on. BTW, nobody should be blocked by anything. I think it's better to continually try to improve the redesign than to wait until some particular thing is available (namely the new API or an Avalon infrastructure). ATM, I can't invest as much time in FOP as I would like. I'm currently doing a few things in the PostScript area that I will commit soon but that's about it. So, if anyone has time to work on the redesign then please do so. Just don't forget Peter's branch. I'd like him to be able to join the redesign development so we can keep focus. 1. A big part of what drives our thinking on the Control structures and API is how to deal with multithreading. I had extended that (in my Control structure ideas) to include the issues of dealing with running multiple documents and multiple output formats. I would like to separate all of these issues into a separate category, which for the moment, kind of belong to Jeremias. Hehe, no code ownership in open source. Again, don't allow yourself to be blocked. If I express my wishes but am unable to put them to reality, then ignore me. I have enough opportunity to include my ideas when I have time. Blocking ourselves is the worst thing we can do ATM. If we can show progress to the outside it will likely attract others. I would like to *temporarily* view FOP as being single-threaded, one document at a time, one output format at a time. In other words, I would like to have permission to temporarily treat Driver as either a singleton or a location for static constructs, which can be used to control the interaction between the various modules, so that I can move that logic out of the modules themselves. I would like to leave the problems of sorting these singleton/static constructs into constructs suitable for multithreading, etc. environments to Jeremias in his API work. It is not my intention to dump this on Jeremias or to generally be lazy, but rather to separate the two issues so that we can each proceed at our own pace. I'll help any way I can with the other as it unfolds. By keeping all of this in Driver, it should at least be easy to see and manage. Here is my +1. +1, if it brings the redesign forward. We have time to sort out these things later. 2. I will then proceed to clean up lines between modules. Success will be measured by the ability to do the following things: 1) to build without compile errors the control and fo classes, and one entry point to Layout (for Control) by themselves (i.e. no fo classes needing layout or area classes), and 2) to build without compile errors the control, area, fo (?) and rendering classes (i.e. no area or rendering classes needing layout classes). Here is my +1. +1 but with the request that the guys with intimate knowledge about properties and such keep an eye on it. 3. Create an AbstractLayoutStrategy class which will encapsulate the interaction between Control and Layout. Make our redesign layout subclass this. (This may actually get done before item 2, as it may make item 2 easier to do). This supposes that LayoutStrategy, and, by implication, the possibility of multiple layout engines, is a good thing. Although I have discussed this before, it has never been canvassed. Here is your chance to agree or disagree. Here is my +1. Choice is always a good thing. It also provides room for experimentation. So +1. 4. Make the layout logic in the maintenance branch conform to the above, subclassing the AbstractLayoutStrategy. I won't check this work into the repository until it is complete, as it bears the risk of failing. I have been amply warned by Joerg that this step will be difficult, maybe impossible, but I feel obligated to try. I will either come back with 1) a way to unify our development efforts, or 2) greater humility and greater knowledge of layout. Neither are bad results. An affirmative vote here implies that retaining our maintenance branch layout (at least in the short term) is a good thing. I want to make it clear that this is not intended to derail or distract from the new layout scheme. I believe (but acknowledge that I am
[VOTE] Re: LayoutStrategy
--- Victor Mote [EMAIL PROTECTED] wrote: 1. In other words, I would like to have permission to temporarily treat Driver as either a singleton or a location for static constructs, which can be used to control the interaction between the various modules, so that I can move that logic out of the modules themselves. +1 Your direction of where you want the processing logic to be--away from the non-apps packages and into apps, is the exact *opposite* of where I want things to be headed! Still, I don't think you should be hobbled by needing to be worried about multithreading issues at this time--come out with your best design as-is. Multithreading, to my limited brain, appears overrated for FOP. For single-CPU processing, multithreading AFAIK isn't going to help. For multiple-CPU, lotsa-reports-getting-generated-every-minute, that is where Cocoon and/or Servlet Containers kick in, and it is *they* who will do the multithreading, correct? (Would they even *want* us to do multithreading? I don't know. If both FOP and those services which call FOP do multithreading, that might have a detrimental impact.) 2. I will then proceed to clean up lines between modules. Success will be measured by the ability to do the following things: 1) to build without compile errors the control and fo classes, and one entry point to Layout (for Control) by themselves (i.e. no fo classes needing layout or area classes), and Doesn't FOTreeBuilder pipe messages to area tree processing? 2) to build without compile errors the control, area, fo (?) and rendering classes (i.e. no area or rendering classes needing layout classes). Here is my +1. -1. I wouldn't make a commitment at this time that no object from most packages needs referencing to another. To accomplish this goal--no area or rendering classes needing layout classes, etc.--you may need to rip out so much functionality into the control classes, make private variables public for control to access, etc. That will cause spaghetti code and code bloat. There goes the elegance! (1) and (2) are noble goals to be strived for, but not to the point of giving the Control classes inordinate access to the member variables/functions of all the packages. But I *highly* encourage better judgments, i.e. the other committers, to weigh in on this. 3. Create an AbstractLayoutStrategy class which will encapsulate the interaction between Control and Layout. Make our redesign layout subclass this. (This may actually get done before item 2, as it may make item 2 easier to do). This supposes that LayoutStrategy, and, by implication, the possibility of multiple layout engines, is a good thing. Although I have discussed this before, it has never been canvassed. Here is your chance to agree or disagree. Here is my +1. -1 (as stated). I think an AbstractLayoutStrategy should not have anything to do with the Control, the Control should be the same for all LayoutStrategies. The latter is of most value to the user--this LS prints better, this one prints faster, etc., etc.--not this LS-CS method doesn't involve the FOTreeBuilder knowing about Area Tree creation, while this LS-CS method does, etc. That's irrelevant to the user. Multiple, pluggable LayoutStrategies work best when there is a predefined begin and end to them within the application. Remember that they may also encapsulate the rendering portion (far right end), so Control (far left end) is the *only* thing currently we can keep constant between the multiple layout strategies. (As we standardize more, perhaps we can even pull out FO Tree Building creation of our the LayoutStrategies as well.) However, from (2) above, if your control classes get so much into the innards of each of the packages, now you have to bring the control classes into the LayoutStrategies. That's my current concern. 4. Make the layout logic in the maintenance branch conform to the above, subclassing the AbstractLayoutStrategy. I won't check this work into the repository until it is complete, as it bears the risk of failing. I have been amply warned by Joerg that this step will be difficult, maybe impossible, but I feel obligated to try. I will either come back with 1) a way to unify our development efforts, or 2) greater humility and greater knowledge of layout. Neither are bad results. An affirmative vote here implies that retaining our maintenance branch layout (at least in the short term) is a good thing. I want to make it clear that this is not intended to derail or distract from the new layout scheme. I believe (but acknowledge that I am possibly wrong), that adopting this plan gets us more quickly to the place where we can work on the new layout, and gives us many other benefits as well. Right now, for example, I need some font work done. I don't feel free to do it in the maintenance branch, but that is the only branch I can use to get any output at all for my
RE: [VOTE] Re: LayoutStrategy
Glen Mazza wrote: --- Victor Mote [EMAIL PROTECTED] wrote: 1. In other words, I would like to have permission to temporarily treat Driver as either a singleton or a location for static constructs, which can be used to control the interaction between the various modules, so that I can move that logic out of the modules themselves. +1 Your direction of where you want the processing logic to be--away from the non-apps packages and into apps, is the exact *opposite* of where I want things to be headed! Still, I don't think you should be hobbled by needing to be worried about multithreading issues at this time--come out with your best design as-is. OK, I need to clarify this. In general, I do not want a bunch of logic moved from non-apps to apps. The only pieces that need to be moved are those that control the flow between the various modules. So, for example, I don't want the fo module deciding to fire off a layout manager, which is what we have now. I want the flow of control to return back to Control (for now, this is Driver), which will then decide, because it knows what LayoutStrategy is in play, and what renderers are in play, and perhaps what user-selected items are in play, whether *it* should fire up Layout, continue building more pieces of the FO tree, etc. 2. I will then proceed to clean up lines between modules. Success will be measured by the ability to do the following things: 1) to build without compile errors the control and fo classes, and one entry point to Layout (for Control) by themselves (i.e. no fo classes needing layout or area classes), and Doesn't FOTreeBuilder pipe messages to area tree processing? I haven't seen that one, but I have seen some other area tree stuff in the FO processing. IMO, we should be able to build an FO tree without knowing anything about layout or area tree, so this is stuff that will be, in the plan I have proposed, moved to one of those modules. 2) to build without compile errors the control, area, fo (?) and rendering classes (i.e. no area or rendering classes needing layout classes). Here is my +1. -1. I wouldn't make a commitment at this time that no object from most packages needs referencing to another. To accomplish this goal--no area or rendering classes needing layout classes, etc.--you may need to rip out so much functionality into the control classes, make private variables public for control to access, etc. That will cause spaghetti code and code bloat. There goes the elegance! If there are needed exceptions to this rule, I'll make a note of them, and explain why they are needed. I can't think of an instance where rendering should need access to layout classes. It needs access to the area tree. If the area tree isn't complete, it should be completed by layout before rendering knows to do anything with the area objects in question. Are you thinking of something specific? I definitely agree that we don't want to rip functionality into the control classes (see discussion above), and I definitely don't want spaghetti. In fact, I am trying to remove what I consider to be a bit of spaghetti. Right now, for example, the fo module starts layout. If you go to LayoutStrategy, the only way it can know what to do at that stage is to carry around information about layout. I don't see a reason for that. IMO, the FO module should be able to build a PageSequence object and return it, and not care who or what it will be used for. If you think of FOP as a pipeline, the stages are as follows: Control | | | | | | | | Parsing/ | | FO Tree | | BuildingLayout Rendering | | | | | | --- -- --- | | | | | | | | XSL-FO Input FO Tree Area Tree Output So we have 4 data points, if you will (maybe there is a technical CS term for this), and 3 processing pipes between them. Each of the processing pipes needs to have access to the data module immediately before and immediately after it. Apparently in the past, the processing was along the model above, but without the Control module, which made it monolithic, i.e. the FO Tree had to be completed before Layout could start. If I understand Joerg, this was changed in favor of our current system. I don't want to go back to monolithic, but I think the right way to handle the concurrency issues (i.e. trying to lay out and render output before we are entirely through with parsing the FO tree), is with the Control layer on top to manage the sequence
