Re: TreeWalker.whatToShow

> 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. 

It seems as if we arrived now back at the starting point of our
discussion where I criticized, that the behavior of whatToShow is not
a real interaction with a filter.  I think, that our main difference
is, that we have different applications in mind where we want to apply
iterators.  So I too want to close the discussion of this issue with
the conclusion:

> There may be a legitimate case for reject-style
> prefiltering as well, but I think that needs more study.

                           * * *

> 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:

Introducing a filtered attribute would not alter the filter
attribute.  

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

Yes, but not so much, because filters are not inherited in iterators. 
You may attach one filter to different iterators.  In disabling the
filter you are changing the behavior of every iterator.  Using an
Iterator.Filtered flag effects only the respective iterator.  What I
had in mind was designing a reusable component for viewing XML source
code unfiltered and by switching a button filtering the tags out.  If
my application has several windows open, it still needs only one
filter.  Having a Filtered flag would improve the reusability of that
component in other applications, where I want the same switch-on/off
behavior with another filter.  So in my view it would be a minor, very
easy to implement, and useful addition to the Iterator's interfaces.

                           * * *

> I've been reminded that we've been forgetting an important point: Specific
> handling for Entity References is designed into the Traversal tools. Both
> NodeIterator and TreeWalker support the entityReferenceExpansion flag,
> which when set false will cause children of EntityReference nodes to be
> rejected.

I have overlooked that. Thanks.

-- 
=====================================================================
 Dieter Koehler, M. A. - dieter.koehler@ppp.uni-bamberg.de
 Mittlere Kaulberg 22, D-96049 Bamberg, +49(0)951-5190726
 "http://www.philo.de/Philosophie-Seiten/": 1000+ Philosophie-Links
 "http://www.philo.de/VirtualLibrary/14.de.htm": Deutsche Philo-Links
 "http://www.philo.de/xml/": Open XML - XML-Komponenten fuer Delphi
=====================================================================

Received on Tuesday, 29 February 2000 09:30:47 UTC