Some more thoughts:

First, the rule could probably use some more flexibility. I.e. it should 
be possible to not only create a DocumentFragment of the XML content 
under the matched element, but also an Element representing the matched 
element itself. In that case, it should be renamed to NodeCreateRule.

The problem I see with implementing this is that the rule does not have 
access to the namespace URI of the matched element, which would make the 
implementation unusable in namespace-aware setups. I've proposed adding 
the namespace URI and local name as arguments to the Rule.begin() method 
(while retaining full backwards compatibility) in the "digester 2.0" 
thread. Maybe this would be a opportunity to make the change.

The other limitation of the rule is that namespace prefixes do not make 
their way into the DOM nodes created, because Digester does not provide 
a way to locate a prefix associated with a namespace URI (it only works 
the other way around, with Digester.findNamespaceURI()). This is not a 
serious limitation IMHO, because you usually don't need the namespace 
prefixes once the parser has resolved the prefixes to the corresponding 
URIs. Anyway, one could think about adding a findNamespacePrefix() 
method to Digester (although an efficient implementation doesn't jump at 
me right now ;-)).

Next, rules that would normally be triggered on elements under the 
element that matched a NodeCreateRule will not be triggered, because the 
rule puts Digester out of action as the ContentHandler. One could think 
about an option to plugin the rule as an XMLFilter, so that Digester 
still gets all the events. I haven't tried that yet, so this may not be 
possible.

Thoughts?

Christopher Lenz wrote:
> So here we go. I've added some test cases and javadoc comments and stuff...
> 
> In essence there's a new rule FragmentCreateRule (named to match the 
> other factory rules), but all the work is done by an inner class called 
> FragmentCreateRule.FragmentBuilder. I've not added a 
> Digester.addFragmentCreate(...) method yet.

-- 
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to