Simon Pepping wrote: > The code you presented seems to be an algorithm implementing > an iterator over a tree. Because it maintains its state, it > can be stopped and resumed at will, provided you keep a > reference to it. > > If LMIter would have a reference to its parent LMIter, and > could return to it after having processed all the siblings, > it would realize such a construct. One could stop the > iteration, retain a reference to the active LMIter, and resume later. > > Not being dependent on the Java stack would make the > programming much more robust. One would have more freedom to > insert actions, without the fear to lose the iteration state > if one would not carefully return to the same function. > > Such a construct would be equally suitable to pull parsing. > The LMIter call to the LM method preLoadNext would request > more child fo nodes, which the parser would provide on this demand. > > On Mon, Dec 13, 2004 at 08:29:43AM -0700, Victor Mote wrote: > > Finn Bock wrote: > > > > > Did you notice that if a FOTree (or a fragment of it) is > serialized > > > to a preorder sequential representation with end markers, the > > > preorder, postorder and child events can be fired > directly from the > > > input stream? > > > > > > IOW the event based layout can work both of a normal > parent/children > > > linked tree and a sequential tree. > > > > Hmmm. I must have totally misunderstood your original > point, which I > > think you expressed much better in your second paragraph above. I > > certainly didn't mean to argue against event-based layout, > which, in > > general, I support, but rather against the idea that an FOTree node > > can necessarily be laid out when it is first encountered. > And I think > > I understand now why you have done the massive propagation of > > properties -- am I correct in understanding that you are > essentially > > flattening the tree so that inheritance must be captured > before that > > flattening takes place? Or are you simply making that an option now? > > Do you want to traverse the FO tree, without relying on the > Java stack, and drive the layout process from there by firing > node events?
Hi Simon: You responded to my last posting in this thread, but your questions seem to be directed to Finn, so I will let him answer them. Please let me know if I have misunderstood. Victor Mote
