History for WebDAV Interfaces, Widgets and Adapters

??changed:
-
WebDAV Interfaces, Widgets and Adapters

  Status

    IsProposal

  Author

    "Michael Kerrin":mailto:michael.kerrin@openapp.biz

  Problem

    Each WebDAV property is defined has a field in some interface. Each
WebDAV property is then rendered via a WebDAV widget, i.e. an adapter
that implements IDAVWidget. All WebDAV widgets must be able to
parse a Python XML dom fragment and extract a value that validates against the
property / field. And visa-versa, each widget renders the property value to a
Python XML dom fragment. For the displayname property with a value of
'WebDAV Proposal' will be rendered has, and parsed from::

      <D:displayname>WebDAV Proposal</D:displayname>

    The current implementation defines all properties to be Text fields. This
is not necessarily true of all properties, and puts the responsibility of
formating certain properties like the creationdate property on the shoulder
of the content type developers who have other things to worry about then
reading RFC2518. This is what widgets are designed to do.

    Second problem is that there are some WebDAV properties that need to
generate URLs. For example the RFC3744 (WebDAV Access Control Lists) defines
the properties 'principal-URL', 'owner', 'group', and
'principal-collection-set' which will all require the generation of URLs. Also
supporting the 'source' property in RFC2518 requires the generation of URLs
also. This functionality is greatly simplified by changing the declaration of
the adapter defining the properties from a single adaptation of the current
context object to a multi-adaptation of the current context object and the
current request to IDAVWidget.

    While an implementation of RFC3744 is in the future, I want to take it into
account because it is a requirement for any CalDAV server.

  Goals

    To tidy up the the WebDAV property definitions, and to effectively use
widgets to render all WebDAV properties.

  Proposed Solution

    Just change the fields in the IDAVSchema interface converting the Text
fields to the appropriate field. See the "interfaces.py":http://svn.zope.org/Zope3/branches/mkerrin-webdav/src/zope/app/dav/interfaces.py?rev=41259&view=markup
in my WebDAV branch, for the current progress.

   On top of these we will need to develop a complete set of WebDAV widgets to
render these properties to and from Python XML dom fragments. All WebDAV
widgets will implement the zope.app.dav.interfaces.IDAVWidget (see "interfaces.py":http://svn.zope.org/Zope3/branches/mkerrin-webdav/src/zope/app/dav/interfaces.py?rev=41259&view=markup), which is very similar in nature to
zope.app.form.IInputWidget but has the added methods of renderProperty and
setProperty. Again, I have made a start at this in the "widget.py":http://svn.zope.org/Zope3/branches/mkerrin-webdav/src/zope/app/dav/widget.py?rev=41259&view=markup file.

   Note that my other WebDAV proposal on namespace management is responsible
for finding the correct widget to use in all circumstances, and which
properties are actually defined on an object.

  Risks

    Backwards compatibility with any existing adapters to IDAVSchema, or with
any custom WebDAV namespace is going to be painful. Due to the nature of this
change, many of these adapters will be required to return a value consistent
with the field defining the property. For example, the creationdate property
now requires all adapters generating its value to return a datetime object.
Where has previously these adapters returned a correctly formatted string for
the creationdate property. Adding logic into the widgets to handle this is not
straight forward.

    Moving from single adapters to multi-adapters also introduces obvious
backwards compatibility problems of its own.