On Dec 14, 2007, at 13:07, Vincent Hennebert wrote:

Andreas L Delmelle wrote:
On Dec 14, 2007, at 11:55, Vincent Hennebert wrote:

Hi Andreas,

+        while (!(ancestor instanceof Flow)
+                && ancestor instanceof Wrapper) {

Might be wrong, but isn’t that the very same as:
    while (!(ancestor instanceof Wrapper))

rhaaaa! (Hitting my head against the table several times.)

Sorry, I meant:
    while (ancestor instanceof Wrapper)
The original loop will stop when:
    ancestor instanceof Flow || !(ancestor instanceof Wrapper)
which is equivalent to simply
    !(ancestor instanceof Wrapper)
So I think the loop may be simplified.

Still not convinced...
The loop should end either if the ancestor is not a Wrapper (a Block, Inline, whatever) or if the ancestor is a Flow (this is implicitly covered by the previous, but this makes sure we stop at the Flow and do not climb further to the PageSequence and the Root)

Doing this with a simple check is impossible, IIC. You would at least need something like:

while (!(ancestor instanceof Wrapper)) {
  ancestor = ancestor.getParent();
  if (ancestor instanceof Flow) {

which would simply move the additional condition into a separate if- block.

And regarding the validation, wouldn’t it be safer to call the
validateChildNode of the nearest non-wrapper ancestor? That way this
class would really keep neutral, and we wouldn’t have to worry about the
implementation of new FO elements.

There's an idea, although, strictly speaking the fo:wrapper has its own

Sure. Wrapper could check for the exceptions it introduces (mainly the
acceptance of fo:markers as its initial children), and defer to its
parent element for the rest. Then that wouldn’t even be needed to
recursively get the nearest non-wrapper ancestor IIC.

Just bumped into one obstacle:
validateChildNode() is a protected member of FONode, and as such, each subclass in the fo.flow package has access only its own version...

* increase the general visibility to public (not sure why this would be desirable; unless there's any other compelling reasons to do so, I'd rather not...) * implement the exception rule for Wrapper in a default implementation in FObj, which would allow delegating to the parent for any neutral items. FObj does have access to its parent's validateChildNode()



Reply via email to