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


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

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

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.

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to