On Tue, 2002-08-13 at 23:15, J.Pietschmann wrote: > Well, I'm not a real Avalon guru (and actually not the > greatest of the Avalon fans, after several dozen hours > of stepping through Excalibur stuff in a Cocoon > application). Therefore I need some explanations (read past > the questions first): > - What's the advantage of transferring functionality of > managing layout from the FO objects to layout managers? > I understand there need objects managing layout of pages > and lines, which do not have a FO counterpart, but for > the other stuff?
No-one has come up with a layout that works from within the FO tree. Getting the layout outside the fo tree really does make a big difference in achieving the layout. For example a block doesn't need to know about lots of other parts of the fo tree in order to do the layout. The layout managers can handle the fo tree and let parts be garbage collected once they are finished with. It is more difficult to do this inside the fo tree. > - If the FO objects are primarily data holders, why > have them at all, instead of using a standard DOM? I think DOM would mean that the whole document must be in memory at once. It is easier to deal with if we can let the FO tree have methods to access views of the data it contains. eg. getting table columns. > - What's the advantage of layout managers being Avalon > components? If anything I would think the the "layout manager set" would be a component, using some sort of factory to create the individual layout managers. I don't see any particular need for this at the moment. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
