cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <>
Subject RE: [RT] Webdavapps with Cocoon
Date Tue, 29 Jul 2003 20:59:22 GMT
Stefano wrote:

> > If I have a resource like
> >
> >
> >
> > and I want to edit, I could ask for
> >
> >
> >
> >"edit"
> >
> > which are all 'orthogonal' ways of asking a different view
> of the same
> > resource accessing it thru a parallel URL space (but with different
> > behaviors)
> >

Marc wrote:

> the only thing I am still strugling with is if there could be an
> automatic way for the clients to know about these other URI's?
> I mentioned the possible use of PROPFIND somwhere down the line
> for communicating READ-ONLY state, in this light this could be
> extended to having a property that describes the URL or 'view' to
> get into editing? (or at least a url to a linkbase that mentiones
> the different allowed view-modes, their role and their URL?)
> on the web-page side of thinks I guess there would just be an
> 'edit' link on the page?

I've been thinking about this same thing too - how to provide write access
to distinct aspects of a website to different people. When a web page is
created by Cocoon, the different aspects are woven together, but the
resulting web page could also be annotated with links to the individual
aspects (as e.g. WebDAV or FTP URLs, so they could be edited).

Here are my thoughts about it:

1) how to keep track of the editable resources used in any particular
pipeline, so that they could be individually exposed for editing?

2) how to encode these URIs for presentation to the user agent?

For the first, my idea was that each stage in the pipeline could insert xml
processing instructions into the SAX output, recording the webdav or FTP
URIs that correspond to the editable resources used in that stage.

This would be a trivial addition to any XSLT in the pipeline, or it could be
added by a specialised "annotator" XSLT, something like:

<xsl:param name="$edit-uri"/>
<xsl:param name="$edit-title"/>
<xsl:template match="/">
	<xsl:processing-instruction name="editor">
	<xsl:copy-of select="."/>

In the sitemap, this could be called like this:

<!-- generate content -->
<map:generate src="content/{1}.xml"/>
<!-- annotate content with an editing link -->
<map:transform src="annotate-edit-link.xsl">
	<map:parameter name="edit-title" value="content"/>
	<map:parameter name="edit-uri"
<!-- style content -->
<map:transform src="style/{2}.xsl"/>
<!-- annotate with style-editing link -->
<map:transform src="annotate-edit-link.xsl">
	<map:parameter name="edit-title" value="style"/>
	<map:parameter name="edit-uri"

Or perhaps a pipeline processor could insert them automatically, based on a
small addition to the current sitemap syntax:


Finally, at the end of the pipeline, the PIs would be harvested by component
that would encode these links for presentation to the user.

The problem is, how to encode these links in a way that a standard client
can handle? It would be really nice to just add elements like this:

<link type="edit-url" title="content" href="/webdav-root/content/blah.xml">
<link type="edit-url" title="skin" href="/webdav-root/skin/zebra.xml">
<link type="edit-url" title="css" href="/webdav-root/css/default.css">

Or RDF could be used instead (again, in conjunction with some client-side
javascript to handle the links).

Of course, no standard client application will know what to do with these.
But with some client-side javascript, these links could easily be converted
into an "aspect-oriented editing toolbar" attached to the browser window

One way would be to write the links (and associated javascript) into the
html pages just before serializing. e.g.

<map:match pattern="*/*.html">
 <map:generate src="content/{1}.xml">
 <map:transform src="xsl/{2}.xsl">

 <!-- inserted this transform to allow editing: -->
 <map:transform src="insert-editing-links.xsl"/>


The downside is that this works only for HTML.

Finally, the option that looks best to me would be to communicate the webdav
URIs to the client browser through a separate channel such as using the
Annotea protocol. These links would appear as annotations to an Annotea
client (e.g. Snufkin or Annozilla). When an Annotea-aware browser loads a
web page, it queries an Annotea server to find any annotations of the page.
Cocoon would be producing both the page and the annotations in this case -
the annotations would be a Cocoon view of the regular output pipeline; a
view in which just the "editor" PIs are harvested and presented as links.

One big advantage of this technique is that it could be used to present
editing links even for binary formats, PDF or JPEG. You could open a JPEG of
a chart; your browser automatically presents you with a link to the
spreadsheet underlying the JPEG; you edit the spreadsheet in your
webdav-capable spreadsheet editor, and refresh the JPEG!

Another advantage would be that non-Annotea clients will be entirely unaware
of the links - you don't have to render different pages for "read-only"
users and the different classes of "editor" users (site admins, content
editors, web designers, etc).



View raw message