Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I just committed a new JCR block. This block provides two features: a Repository component, and a "jcr:" protocol.
Awesome news!
The Repository component is nothing more than the standard javax.jcr.Repository interface, but provides a way to centrally define how to access the repository (Jackrabbit conf file, JNDI, etc) and how to obtain credentials to log into the repository. There's currently only one concrete implementation that uses Jackrabbit.
That's very cool... I needed something like this for Linotype.
The JCR source factory is more interesting, as it provides a traversable and modifiable source that hides away the details of the repository structure and node types. To achieve this, we need to configure it by defining a mapping from node types to "files" and "folders" that will be visible through the "jcr:" protocol.
The result is that we can now use a JCR repository in Cocoon just like we use the regular filesystem.
As an example, here's how this source factory is configured for the standard filesystem-like node types defined by JCR:
<component-instance class="org.apache.cocoon.jcr.source.JCRSourceFactory" name="jcr">
<folder-node type="rep:root" new-file="nt:file" new-folder="nt:folder"/>
<folder-node type="nt:folder" new-file="nt:file"/>
<file-node type="nt:file" content-path="jcr:content" content-type="nt:resource"/>
<file-node type="nt:linkedFile" content-ref="jcr:content"/>
<content-node type="nt:resource"
content-prop="jcr:data"
mimetype-prop="jcr:mimeType"
lastmodified-prop="jcr:lastModified"
validity-prop="jcr:lastModified"/>
</component-instance>
how do you expand the prefixes in the attribute values?
I don't ;-)
All methods in the JCR API use prefixed names, and prefix mappings are stored within the repository itself.
well, this is not entirely correct. you can overload the prefixes in your workspace ;-)
So I expect the mapping writer to be consistent with prefixes defined in the repository.
this is a huge mistake. if I take my content and your content and merge them into a single repository, then we could have the exact same prefixes, mapped to a different namespace and the JCR API is totally consistent as long as you specify that prefix in the workspace you are using.
I agree that by default the default prefix is good enough, but in the long term we might want to keep the door open for overloading prefixes in the workspace.
Now if we want to use full namespace URIs, we can also accept the notation that's used in some places in JCR, i.e. "{full-uri}name".
that's ugly :-) I'd much rather use the XSLT-like prefix expansion based on the current namespace prefix description of the element contenxt in the XML infoset.
More detailed information about this configuration is given in o.a.c.jcr.source.JCRSourceFactory's javadoc.
This source factory is still a bit primitive regarding all features provided by JCR. Future enhancements include querying the repository, handling workspaces, node properties, versions, etc.
Your feedback and opinions about this initial implementation and its future evolutions are more than welcome!
In linotype, what I needed was a way to store new items in the repository and then query the repository for the last n in reversed chronological order (LIFO).
There are many ways we can glue query capabilities to JCR in cocoon, I would like to discuss with you people what is best way to do that and what are the requirements.
My initial thoughts about this is to use URI parameters for querying, e.g. "jcr://?xpath=/news/items[position() < 10]" and have this return a collection source, i.e. one that has children that would be the query results.
The parameter name is the query language to be used (e.g. xpath, sql, etc).
sure, that's a start, let's see how far along we can go with that.
-- Stefano.
