Attention
You are looking at outdated documentation for version 1.x. A newer version is available.
4.5. Virtual WebDAV provider¶
4.5.1. Examples¶
Given these 3 ‘resources’:
Title | Orga | Status | Tags | Attachments |
---|---|---|---|---|
My doc 1 | development | draft | cool, hot | MySpec.doc MySpec.pdf |
My doc 2 | development | published | cool, nice | MyURS.doc |
My doc (.) | marketing | published | nice | MyURS.doc |
this dynamic structure is published:
A resource is served as an collection, which is generated on-the-fly and contains some virtual files with additional information:
4.5.2. Usage¶
To publish the sample virtual resources, simply add thes lines to the configuration file:
# Publish a virtual structure
from wsgidav.samples.virtual_dav_provider import VirtualResourceProvider
addShare("virtres", VirtualResourceProvider())
4.5.3. Module description¶
Sample implementation of a DAV provider that provides a browsable, multi-categorized resource tree.
Note that this is simply an example with no concrete real world benefit. But it demonstrates some techniques to customize WsgiDAV.
Compared to a published file system, we have these main differences:
- A resource like
My doc 1
has several attributes likekey
,orga
,tags
,status
,description
. Also there may be a list of attached files. - These attributes are used to dynamically create a virtual hierarchy.
For example, if
status
isdraft
, a collection<share>/by_status/draft/
is created and the resource is mapped to<share>/by_status/draft/My doc 1
. - The resource
My doc 1
is rendered as a collection, that contains some virtual descriptive files and the attached files. - The same resource may be referenced using different paths
For example
<share>/by_tag/cool/My doc 1
,<share>/by_tag/hot/My doc 1
, and<share>/by_key/1
map to the same resource. Only the latter is considered the real-path, all others are virtual-paths. - The attributes are exposed as live properties, like “{virtres:}key”,
“{virtres:}tags”, and “{virtres:}description”.
Some of them are even writable. Note that modifying an attribute may also
change the dynamically created tree structure.
For example changing “{virtres:}status” from ‘draft’ to ‘published’ will
make the resource appear as
<share>/by_status/published/My doc 1
. - This provider implements native delete/move/copy methods, to change the
semantics of these operations for the virtual ‘/by_tag/’ collection.
For example issuing a DELETE on
<share>/by_tag/cool/My doc 1
will simply remove the ‘cool’ tag from that resource. - Virtual collections and artifacts cannot be locked.
However a resource can be locked.
For example locking
<share>/by_tag/cool/My doc 1
will also lock<share>/by_key/1
. - Some paths may be hidden, i.e. by_key is not browsable (but can be referenced) TODO: is this WebDAV compliant?
The database is a simple hard coded variable _resourceData
, that contains
a list of resource description dictionaries.
A resource is served as an collection, which is generated on-the-fly and contains some virtual files (artifacts).
In general, a URL is interpreted like this:
<share>/<category-type>/<category-key>/<resource-name>/<artifact-name>
An example layout:
<share>/
by_tag/
cool/
My doc 1/
.Info.html
.Info.txt
.Description.txt
MySpec.pdf
MySpec.doc
My doc 2/
hot/
My doc 1/
My doc 2/
nice/
My doc 2/
My doc 3
by_orga/
development/
My doc 3/
marketing/
My doc 1/
My doc 2/
by_status/
draft/
My doc 2
published/
My doc 1
My doc 3
by_key/
1/
2/
3/
When accessed using WebDAV, the following URLs both return the same resource ‘My doc 1’:
<share>/by_tag/cool/My doc 1
<share>/by_tag/hot/My doc 1
<share>/by_key/1