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
