OK, I rewrote generateQuery so that it can deal with namespaces other than
DAV:

    /**
     * Generate the query body.
     *
     * @return String query
     */
    public String generateQuery() {

        if (query != null)
            return query;

        XMLPrinter printer = new XMLPrinter();
        printer.writeXMLHeader();
        printer.writeElement("D", "DAV:", "propfind",
                             XMLPrinter.OPENING);

        switch (type) {
        case ALL:
            printer.writeElement("D", "allprop", XMLPrinter.NO_CONTENT);
            break;
        case NAMES:
            printer.writeElement("D", "propname", XMLPrinter.NO_CONTENT);
            break;
        case BY_NAME:
            printer.writeElement("D", "prop", XMLPrinter.OPENING);
            while (propertyNames.hasMoreElements()) {
                String propertyName = (String) propertyNames.nextElement();
                    int index = propertyName.lastIndexOf(":");
                    if(index == -1) {
                        printer.writeElement("D", propertyName,
                                                   XMLPrinter.NO_CONTENT);
                    }
                    else {
                        String prefix = propertyName.substring(0, index+1);
                        String local = propertyName.substring(index+1);
                        printer.writeElement("ZZ", prefix, local,
                                                   XMLPrinter.NO_CONTENT);
                    }
            }
            printer.writeElement("D", "prop", XMLPrinter.CLOSING);
            break;
        }

        printer.writeElement("D", "propfind", XMLPrinter.CLOSING);

        query = printer.toString();
        return query;

    }

The only real difference is that in the BY_NAME case, a call to
propertyIndex.lastIndexOf(":") finds the last occurrence of ":" in the
property name.  I use lastIndexOf because some of the properties I am
interested in querying, from Microsoft Exchange, have a prefix of the form:

        urn:schemas:httpmail:fromemail

So obviously looking for the first occurrence of the colon would not work in
this case.  If no colon can be found in the string the namespace is assumed
to be DAV: and printer.writeElement("D", propertyName,
XMLPrinter.NO_CONTENT) is called, making use of the fact that the DAV:
namespace was declared as part of the <propfind> element.

If an occurrence of ":" is found the property name is separated into its
prefix and local name parts and printer.writeElement("ZZ", prefix, local,
XMLPrinter.NO_CONTENT) is called defining a namespace "ZZ" scoped to this
element.

Everything works, but there is one thing that I'm wondering about.  Defining
a namespace for each non DAV: property element is redundant and leads to
increased network traffic if a large group of properties share the same non
DAV: namespace.  A much more elegant solution would be to preparse the
propertyNames Vector and generate a hash containing unique namespaces and
abbreviations to represent those namespaces in XML.  A new writeElement
method could then be added to XMLWriter which took a hash as a parameter and
declared all of the namespaces associated with the property names within the
<propfind> element.

Would this be a worthwhile improvement?

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 5:37 AM
To: [EMAIL PROTECTED]
Subject: RE: Using prop find for properties whose namespace is not DAV


> I'm wondering if there is an easy way to query for properties
> that don't have DAV as their namespace.  In looking at the source for
> PropFindMethod I notice that in the generateQuery function, DAV is
hardcoded in as the
> namespace.  I would like to query objects for properties
> whose namespace is not DAV?  The only way I can see to do it is to call
> setQueryString and passing in an XML string I generate myself.  Am I
missing
> something or is this the only way to do it?  Also, if I was to rewrite
> generateQuery so that it correctly dealt with different namespaces on
properties, is this
> something that people would be interested in?

Indeed, you are correct.
Any improvement is welcome, but please provide also backward compatibility
code.


Dirk

Reply via email to