--- 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]
