Hi Robert,
see intermixed:
robert burrell donkin wrote:
> On Wednesday, August 28, 2002, at 06:05 PM, Christopher Lenz wrote:
>> I'm playing with Digester, trying to use it to transform XML WebDAV
>> request bodies into my custom object model, and I've encountered a
>> couple of problems quite early in the process.
>>
>> The first is that WebDAV allows elements of arbritrary namespaces
>> inside the standard elements (custom properties), and those elements
>> need to be processed.
>>
>> Example from the spec (RFC 2518):
>>
>> <?xml version="1.0" encoding="utf-8" ?>
>> <D:propfind xmlns:D="DAV:">
>> <D:prop xmlns:R="http://www.foo.bar/boxschema/";>
>> <R:bigbox/>
>> <R:author/>
>> <R:DingALing/>
>> <R:Random/>
>> </D:prop>
>> </D:propfind>
>>
>> The structure and semantics of the elements in the "DAV:" namespace
>> are well defined and reflected in the object model, but the other
>> elements in to be processed, in this case by simply storing
>> "QualifiedName" objects in a list.
>>
>> So I've set up the rules in a RuleSet like this:
>>
>> digester.setRuleNamespaceURI("DAV:");
>
> (i'm not an expert on namespace support in digester, so i could be wrong
> but...)
>
> this looks a bit wrong to me. shouldn't this use the public namespace
> URI rather than the local prefix?
Well, in this case "DAV:" *is* the namespace URI (and, yeah, it's a
weird choice ;o)).
>> digester.addRule("propfind/prop",
>> new ObjectCreateRule(Propfind.class));
>> digester.addRule("propfind/prop",
>> new SetNextRule("setPropfind"));
>> digester.setRuleNamespaceURI(null);
>> digester.addRule("propfind/prop/?",
>> new FactoryCreateRule(QualifiedNameCreationFactory.class));
>> digester.addRule("propfind/prop/?",
>> new SetNextRule("addPropertyToFind"));
>>
>> First thing to note is the necessity to set the rule namespace URI
>> to null for the rules that should process the properties. Obviously,
>> those rules would match a "propfind/prop/?" combination even if the
>> namespace URIs of the elements "propfind" and "prop" were not "DAV:".
>> I don't see a solution to that, however.
>
> hmmm...
>
> i'm a bit confused by this. are you wanting to do stuff like matching
> every namespace which isn't DAV?
The exact logic I'd need would be: match any direct child of elements
matched by the pattern "propfind/prop" (where both propfind and prop
need to be in the "DAV:" namespace), regardless of the namespace or
local name of the child element.
Maybe this would a candidate for inclusion in ExtendedBaseRules?
However, I see no straightforward way to implement it...
>> The next problem is that in QualifiedNameCreationFactory, I need
>> access to the namespace URI of the current element to be able to
>> instantiate the QualifiedName object. I do have access to the local
>> name of the element through Digester.getCurrentElementName().
>>
>> As I've found no other way to accomplish this, I've hacked Digester to
>> add a getCurrentNamespaceURI() method. That modification works for me,
>> but maybe there's a better solution ?
>
> adding that property's the best way to go.
>
> if you like, submit a patch against CVS HEAD with a test case to the dev
> list (or to me personally) and i'll look at committing it. if you don't
> fancy doing that, post a reply and i'll try to find some time to do it
> myself.
I'll submit a patch then, no problem.
> there are better solutions - but see later...
>
>> BTW, I think it would be far more natural if the namespace URI and the
>> name of the element would be passed into the Rule's begin() method.
>> Especially when considering the ExtendedBaseRules' parent match
>> feature, where the name of the element isn't as obvious as with the
>> standard Rules implementation...
>
> it is more natural - but changing the rule interface would break
> backwards compatibility :)
Good that Rule isn't an interface, right? ;o)
A new method begin(namespaceURI, name, attributes) could be added to the
Rule base class, which by default delegates to begin(attributes).
Digester then starts calling the new method, and the old Rules will
still work, while new ones can use the new method directly.
Or am I missing something?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
