Andreas L. Delmelle <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED

--- Comment #2 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-06-22 
06:41:32 PST ---
Looked closer at this one, and simply swapping the call-sequence of
startOfNode() and addChildNode() broke some table-related testcases, since the
table-code relied on startOfNode() being called before addChildNode() (leading
to some dubious lines of code in AbstractRetrieveMarker.cloneSingleNode()...)

Proposed solution: introduction of a public finalizeNode() method in FONode,
whose main purpose will be to perform 'finishing' tasks. The default
endOfNode() implementation in FONode invokes this method without registering
any event. Subclasses can then add overrides like:

super.endOfNode(); // trigger finalizeNode();
getFOEventHandler().endXXX(); // send endOfNode() notification

As such, AbstractRetrieveMarker can then call finalizeNode() to avoid sending
the event twice.
The initialization code for the table-related FOs would be moved to a
processNode() override (which is already public), so that the calls to
startOfNode() can also be avoided, and both methods can retain their protected
visibility in the table-FOs.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to