WebDAV Interfaces, Widgets and Adapters

WebDAV? Interfaces, Widgets and Adapters

Status

IsProposal?

Author

Michael Kerrin

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 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), 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 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.