Hi Laurent
Your patch is a good idea - I've thought of doing something similar. I'm
tempted to go one further - lets use XSLT patterns. What are XSLT patterns?
Well essentially they are like XPath expressions, they are used in XSLT in
the <xsl:template match="pattern"> tag.
Using your example for a moment...
From: "Developer Laurent Caillette" <[EMAIL PROTECTED]>
> <h1>
> <p>
> stuff 1
> </p>
> <h2>
> <p>
> stuff 2
> </p>
> </h2>
> </h1>
So a pattern could be "p" which would match all <p> elements. Or a pattern
could be "h1/p" which would match all <p> elements which are children of a
<h1> element. Or it could be /h1/h2/p which could match using absolute
paths. We can also add filters like this "p[@style='bold']" and so on.
The original use case for ElementHandler was simply to chunk an XML document
into 'rows' when processing massive documents. I think there is another use
case, splitting the document into parts, based on XSLT Patterns, which each
get processed as they arrive by handlers - rather than building the whole
document then navigating to find the parts.
Currently we have an implementation of XSLT patterns in the org.dom4j.rule
package - this actually contains an implementation of the XSLT rule engine
(or 'processing model' as its referred to in the XSLT spec). XSLT is a
similiar thing to what we've just described - handlers are associated with
different XSLT patterns. Though in XSLT there is a 'conflict resolution'
protocol to ensure that only *one* handler gets called for a single pattern
http://www.w3.org/TR/xslt11/#conflict
I'd expect that this 'only one handler gets called' part of XSLT is not
needed in this case, we'd want to notify all handlers that match a given
element.
So something along the lines of...
package org.dom4j.util;
/** A Composite ElementHandler which allows
* individual ElementHandler objects to be added
* with an individual XSLT pattern.
*/
public PatternHandler implements ElementHandler {
public void addHandler( String pattern, ElementHandler handler );
public void removeHandler( String pattern, ElementHandler handler );
...
}
which could internally use the org.dom4j.rule.Pattern interface. This
interface can tell you the name of the element that gets matched so we can
do fast evaluation. Essentially the pseudo code is something like this...
Pattern pattern = DocumentHelper.createPattern( "h1/p" );
...
Element element = ...;
if ( pattern.matches( element ) ) {
// call the handler...
}
It should be fairly easy to create one of these PatternHandler objects -
then we'd be able to handle full XSLT patterns which would be really cool.
Then as a user you could do...
PatternHandler patternHandler = new PatternHandler();
patternHandler.add( "p", someHandler );
patternHandler.add( "h1/p", someHandler2 );
patternHandler.add( "h1//p", someHandler3 );
patternHandler.add( "p[@style='foo'", someHandler4 );
patternHandler.add( "/h1/p", someHandler5 );
// now use it
SAXReader reader = new SAXReader();
reader.setDefaultHandler( patternHandler );
Document document = reader.parse( "foo.xml" );
Does this sound like a good idea to you? Do you want to try build one or
shall I? If you want to try, the org.dom4j.rule.Mode class, in particular
the getMatchingRule() method shows you how the XSLT processing model works,
finding the best match Pattern (Rule) for a given Node.
> My opinion about dom4j : the more I use it, the more I like it. JDOM or
> W3C DOM do nothing the way I want. dom4j simply rocks. Thanks for making
> good software. Please continue !
Thank you - glad you like dom4j!
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
