jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pickering <benpicker...@gmail.com>
Subject Re: webdav configuration api
Date Sat, 09 Apr 2005 18:43:41 GMT
I assume you're talking about import/export via WebDAV only.  I'd be
interested in thoughts in applying this to JCR objects in general --
the ability to define different interfaces for setting and getting
data for some objects.

Here's a Communique example.  The table editor applet sets an Atom
value that is a tab/newline-separated string.  It's a nightmare to
work with in code.  Why not provide a TableAtom that provides
getValue(x,y) and setValue(x,y,value) that manages the conversion to
and from the complex string.  You'd just cast the Atom to TableAtom to
access the new features, and the basic getString() would obviously
work just as before.

This is an easy example and it's easy to think of many more applications:
* validation
* extracting media metdata
* applying an XSLT stylesheet to XML data
* helper functions for streaming data around (great for binary streams)
and so on

It would be nice to have this implemented in the repository, but
obviously you could also make a decorating factory that could look up
what type of atom it was and wrap the basic JCR object in something
more useful.

The former approach has the benefit of being easy to use from the
client's perspective, but the latter is perhaps less invasive.

On Apr 9, 2005 5:45 PM, Tobias Strasser <tobias.strasser@gmail.com> wrote:
> > I don't see how common chain would help in the import/export task :(.
> > AFAIK chain is used to run a sequence of commands but in this case only
> > one command should handle each request, there's no complex processing
> > flows. It would be useful for performing custom operations before and
> > after import/export but I don't see it as a common requirement. Am I
> > missing something?
> well, the webdav server needs some mechanism to create jcr-items from
> a webdav resource, and vice versa. the most generic way is to create a
> nt:file + nt:resource for a non-collection resource and a nt:folder
> for a collection. an example for a more sophisticated import is
> deserializing a XML file, thus allowing other applications to search
> and manipulate the desrialized XML in the repository. another example
> is to extract more information from a imported resource, eg: ID3 tags
> from a mp3-file, format, colorspace, dimensions from a image etc.
> we need a plugable mechanism for import/export. we thought of a chain
> of handlers, that sequencly are asked to perform the respective import
> or export operation. instead of building an own implementation of such
> a framework, commons-chain seems to be a good alternative. i made
> first steps in implementing those handlers using commons-chain, and it
> seems worth to follow this path. imo, one chaining-framework is as
> good as something else. if jakarta provides such a framework it makes
> sense to use this one.
> the need for configurable, plugable import/export handlers is
> undoubted. as first step, we will provide those handles, using
> commons-chain. but if it shows, that there is a better alternative, i
> think we can easily switch to something else.
> cheers, tobi
> --
> ------------------------------------------< tobias.strasser@day.com >---
> Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---


View raw message