On Thu, 2002-11-21 at 12:43, Victor Mote wrote: > To conclude, if I were designing this system from scratch, based on what I > know right now, I would: > 1. Use DOM for both the fo tree & the area tree.
I don't know whether I would call it a DOM but the area tree is an independant data structure that contains all the information necessary to render the document. > 2. Write them to disk when necessary, hiding all of this from the layout > managers. This has already been done for the area tree. I use the CachedRenderPagesModel all the time. If it cannot render the page immediately then it saves it to disk. The layout managers only know about adding areas to a page and then adding the page to the area tree. For rendering it can dispose of the page once rendered, for awt viewer it could save all pages to disk and load when necessary. As described here (written a long time ago and needs updating): http://xml.apache.org/fop/design/areas.html I don't see why you would need all the fo tree available, each page sequence is independant for the flow and often each page can be finished before the next page. > 3. Use an event-based layout mechanism so that the fo tree doesn't even have > to be there to get layout work done. Depends exactly what you mean but I think that is the general idea, care to implement it. > I am sure I can be talked out of this by someone smarter, but I wanted to > lay out the whole line of reasoning. My apologies to Peter and anyone else > who may have been working on these points before. I am just now getting > around to them. > > After further consideration, my use of "event-based" above may be too > strong. Probably what I mean is more along the lines of API-based. In a > WYSIWIG environment, the event would probably trigger an API action, but > that action could be invoked another way as well. I am too tired to rewrite > it -- I hope you know what I mean. > > This final thought is really a question which was briefly addressed during > our recent weekend clarification about the role of the maintenance branch, > and which I wish to apply specifically to the above thoughts. Does or could > the new design give us the ability to (with say, a configuration option) > choose between Layout Philosophy A and B? By this I mean 2 (or more) layout > packages coexisting in the same code base, and sharing common resources that > can be selected (configurable perhaps). If so, then we can play with these > ideas at our leisure, compare them in various ways, transition between them > if necessary, and maybe even keep both to be used in various circumstances. > I think someone (Jeremias perhaps) had indicated that something along these > lines would be possible, but that may have been at a lower level than what I > am discussing here. This should be quite simple to do. There would be a basic interface set for the layout managers when being created by the fo tree. We could possible have a common one for inline objects. The actual layout implementation could then be changed. Again, this will need to be implemented. > I don't mean to rock the boat. I guess I am kind of like a three-year-old > who asks "why" and "why not" all of the time to the annoyance of all around > him -- I am still trying to learn the basics. Thanks for your patience. I keep getting the feeling that everyone is saying the current design is wrong and here is a better idea, which turns out to be the same as the current design. When will people start doing it? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]