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 (else). > 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]
