On 2002.01.11 10:38 Bertrand Delacretaz wrote: > If I understand right, FONode objects should be disposed of as soon as > possible - in this case I'd suggest creating a StructureEventListener as > follows: > > actors and goals: > ag1. FOP creates FONodes while parsing the input stream > > ag2. FOP wants to dispose of FONodes as soon as possible, to be able to > work > on SAX event streams without keeping everything in memory > > ag3. StructureEventListener wants to use FONodes as soon as they are > created, > and often needs specific FONodes to stay around until they have been used > > (rendered)
This sounds right. > contracts: > c1. zero to N StructureEventListeners can register with an FONode to > receive StructureEvents > > c2. an FONode that does not have its own list of StructureEventListeners > uses that from its parent > > c3. StructureEvents are like: FONodeStartEvent, FONodeEndEvent, > FONodeAttributesEvent which are sent at the end of the corresponding > FONode > methods > > c4. FONode has an "usage counter", that prevents it and its parents from > being disposed of until its value is zero (or do we want to rely on the > gabage collector only for this?) > > In this way, StructureEventListeners (like an RtfRenderer based on jfor > code) > could release FONodes early if they are able to render on the fly, or > keep > them around if needed. > > How does this sound? This doesn't quite feel right to me. Why do we need to count things if those that need them simply keep a reference. Do we need to have this completely separate method of reading the fo tree (layout managers is the other) when both do some similar things. I'm not sure, I just can't picture how it should work at the moment. We need: - start and end of document - start and end of page sequence - resolved properties - static areas - add info after end of block level object: block, table, list etc. I don't quite understand how these things fit in the rtf. > Should we call everything StructureEvent... or FONodeEvent... or > FOStructureEvent...? > > - Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
