Hi Dave

> It just occurred to me that it might be more powerfull/flexible
> if the DispatchHandler doesn't automatically prune the tree
> for any element which has a ElementHandler registered, but
> rather leave it up to the ElementHandler itself to either
> prune the tree or not.

I was just thinking the same thing! I agree.

> If you agree with this, then do you think that the ElementHandler
> should perform the appropriate detach() themselves

I think so. Its just a matter of calling detach() on the current element.

Since a developer will be writing an ElementHandler to process the current
Element in question, they just need to add a single line of code to 'prune'.

e.g.

public class MyFooHandler implements ElementHandler {

    public void onStart( ElementPath path ) {
    }

    public void onEnd( ElementPath path ) {
        Element element = path.getCurrent();

        // here I might want to only prune certain elements
        if ( something ) {
            // do something with element....

            element.detach();
        }
    }
}

So why don't we just leave it up to the developer to do the pruning? Just
giving them a clean API to allow one or more ElementHandler's to be
registered (either globally or based on a path expression) is enough I
think. In fact I think thats *really* cool.

Sound a reasoable approach? Let developers do whatever they wish, easily.


> (I don't really
> like that...) or should we add another method say:
>
> public boolean pruneTree()
>
> to the ElementHandler interface, which each ElementHandler can
> implement to tell the DispatchHandler if it should prune the tree
> for the current Element?

I'm a little against this approach. Whenever I've a choice I'd rather fairly
minimal code (such as 1 line) be explicit in code.
Also the developer might decide whether they want to prune or not inside a
logical branch of the onEnd() method, so they might as well prune when
they've decided to do so, rather than get called back again by the
DispathHandler and preserve the boolean state between method calls.

This general approach of prune when you need to might also get developers
used to the idea that they could adorn or enrich or prune nodes as they are
built using the event mechanism as an alternative approach to implementing a
DocumentFactory.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev

Reply via email to