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))
?

Not really.
The while-loop continues until
* either it finds an instance of Flow (a fo:flow or fo:static-content),
* or something that is not a Wrapper.

The check immediately below finds out whether we have a Flow, so that would mean that either the current fo:wrapper is a direct child to an fo:flow/fo:static-content, or it has no other ancestors than fo:wrappers, and the last one is a direct child to a Flow.

Your version will run indefinitely, unless there is a Wrapper somewhere in the ancestry...

The two situations being checked for are:

<fo:flow ...>
  ...
  <fo:wrapper>...

and

<fo:flow ...>
  ...
  <fo:wrapper>
    <fo:wrapper>
      <fo:wrapper>...etc.


Once there is another type of node in between, the switch isFlowChild will be false, and everything proceeds as before.


<snip/>

     protected void validateChildNode(Locator loc, String nsURI,
     String localName) throws ValidationException {
@@ -58,9 +74,30 @@
                     "(#PCDATA|%inline;|%block;)");
             }
         } else if (isBlockOrInlineItem(nsURI, localName)) {
+            if (isFlowChild
+                    && isInlineItem(nsURI, localName)
+                    && !isNeutralItem(nsURI, localName)) {
+                invalidChildError(loc, nsURI, localName,
+ "fo:" + localName + " not allowed as child of an fo:wrapper " + + "that is a child of an fo:flow or fo:static-content");
+            }
             blockOrInlineItemFound = true;
         } else {
             invalidChildError(loc, nsURI, localName);

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 content-model. But you are right, in that it only disallows parts of that content- model, if its parent would not allow them as children...

Going to try this approach, and will get back to you on that.


Thanks for the feedback.

Cheers

Andreas

Reply via email to