Andreas L Delmelle wrote:
> 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) {
>>
>> 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)

But as you said this is already covered by the previous test! In other 
words: the loop should end either if the ancestor is not a Wrapper (a 
Block, Inline, whatever), or if the ancestor is not a Wrapper (a 
Flow...).


> 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) {
>     break;
>   }
> }

But the test inside the loop is not necessary, since it will 
automatically be performed at the end of the loop (more precisely: 
before starting the next iteration). If ancestor is a Flow, then 
ancestor is not a Wrapper, then the while loop will stop there. So the 
following should be enough:
    while (ancestor instanceof Wrapper) {
        ancestor = ancestor.getParent();
    }
    // Once we get here we have !(ancestor instanceof Wrapper)

That’s simply the way the while loop works. Had you used a repeat loop 
(do...while in Java), this would have been another question.
... Unless I’ve completely missed something.


<snip/>
> 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...
> 
> Options:
> * 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...)

Yeah, we’re hitting a limitation of Java here. Basically we’re missing 
a keyword allowing classes of a sub-package to access the method. Making 
it public with a proper comment is still the less ugly way to do in my 
opinion.


> * 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()

Well we rather not clutter up FObj with a method that only applies to 
Wrapper. Were it useful to many subclasses, why not, but that’s not the 
case here. I don’t think FOP will ever implement the other neutral FOs 
(related to dynamic content) that might have a use of it.

Vincent


-- Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to