Glen Mazza wrote:

> From my perspective, apps is pretty well cleaned up
> now.  (I'll try my luck at the properties and the
> AWTRenderer next.)

Peter has done some work on properties, but I am not clear on what the
status of that is. If I understood, he was going to place the properties as
fields directly in the class instead of as separate objects. That seemed to
me like a Good Thing, as it seems to make everything lighter, smaller, and
cleaner. But then I later got the impression that he was basically
abandoning the FO Tree entirely in favor of his pull parsing, so I was
pretty confused about all of it. I don't have a good feel for what the rest
of the committers think about this. IMO, changes to properties would seem to
be low priority, since it works. However, a reasonable case can be made that
cleaning it up simplifies layout, which is very, very important. (Really,
the tack I am on is an effort to segregate and simplify so that layout will
be cleaner and more fun (?) to work on.) At the very least, please tell us
what your plans are for properties.

> Document also seems to fit well in the apps package
> (it encapsulates a Driver object, also it may be
> replacing Driver in the future).  So unless it makes

I think of Driver as corresponding to my "Session" concept. Driver/Session
potentially has a many-to-one relationship with Document. We have debated
whether we want to allow that many-to-one relationship to actually exist,
but IMO, whether we do or not, there is value in keeping the concepts
separate. Document does store the Driver object, mostly as a reference. You
can now use getDocument() from any FONode subclass to find the Document
object, and therefore, you can also find the Driver object. There is a lot
of refactoring to do in Driver and Document after I get everything bubbled
up there that I want. Right now, I am just trying to avoid breaking anything

> your coding easier, you may just want to place that
> class in apps and not bother with the Control package.
>  (But I don't know how large you intend the Control
> package to get.)

I'm don't care much which package it is in. I kind of thought that you and
Jeremias were heading toward having apps only have command-line level and
API stuff in it, and control is kind of the central clearing house that
takes input from command-line or an embedded app, and runs it. Ideally
control would have Driver/Session, Document, perhaps a RenderContext, and
perhaps some Render control concepts.

Victor Mote

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

Reply via email to