Re: TreeWalker.whatToShow

>So if we have a resolveReferences flag in the DOM, is there any longer
>a need for the skip behavior of TreeWalker.whatToShow instead of the
>reject behavior?

What about the folks who want to skip the Elements and just gather all the
text from a subtree?

Yes, there's a legitimate use for both Skip and Reject, which is why
filters are allowed to return both. And yes, whatToShow is currently a
shortcut only for the Skip case, and as a "pre-filter" it interacts with
the user-written filter. There may be a legitimate case for reject-style
prefiltering as well, but I think that needs more study.

>> >NodeIterator and TreeWalker interface:
>> >    filtered of type boolean
>>
>> How would this differ from, eg, (NodeIterator.getFilter()!=null)?
>
>What I had in mind was the question, what would be the most elegant
>way to switch a filter off and on again in an object orientated
>programing language.
>
>If we do it your way, the applications has to be
>aware of the filter that was attached to an iterator before it was
>switched off

Since the filter attribute of an iterator or treewalker is immutable, you
can't currently switch it on and off at that level. However, you can design
that switch into the filter itself:

     void setDisabled(boolean newvalue)
     { this.isDisabled=newvalue;
     }
     // ... //
          if(isDisabled)
               return FILTER_ACCEPT;
          // Normal filter logic follows that cut-out //

and use something like ((MyFilter)tw.getFilter()).setDisabled(newstate) to
toggle it. Still very OO.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 28 February 2000 13:02:56 UTC