cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: New JCR block
Date Mon, 25 Apr 2005 16:33:42 GMT
Sylvain Wallez wrote:
> 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.


Mime
View raw message