[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded design like Peter West's approach. Can anyone think of a reason that all the FO-building and layouting process for one processing run may run within more than one thread? I don't think threre is one if the SAX event delivery is always within one thread (big if). If there isn't I believe we could make use of a ThreadLocal to put some shared data that will be easily accessible from all involved components. Initialize the ThreadLocal in startDocument() and clear it in endDocument(). I realize there's a certain risk involved but it could really shorten the access ways for shared data especially for the FO tree, if that's really a problem (I'd also like to know if it really is. Anyone?).
A (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document.
My preference would be to explicit pass the shared data (in this case the FOEventHandler) to the classes that needs it. If the recursion Glen discovered is deemed too slow, then store the FOEventHandler in an instance field for each FONode.
regards, finn
