jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ard Schrijvers <a.schrijv...@onehippo.com>
Subject Re: On virtual content
Date Wed, 19 Sep 2012 19:46:05 GMT
Hi,

On Tue, Sep 18, 2012 at 5:56 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> We have a good reasons for adding support for "virtual content", i.e.
> content that's accessible through the Oak API, but that's not actually
> stored in the underlying MicroKernel. The main reasons that come to my
> mind are:
>
> 1) As we implement workspace support, we need some way to make the
> shared /jcr:system subtree visible to all workspaces.
> 2) The JCR spec mandates some auto-created content to be available
> already before transient changes are persisted. That should be fairly
> straightforward to implement with virtual content.
> 3) We could "mount" parts of external repositories to a single content tree.
> 4) We could implement "views" like in Hippo's facet feature.
>
> The same feature could probably also be easily used to hide existing
> content for access control or other reasons.
>
> So how could we best implement something like this?
>
> The implementation should probably go to somewhere between the Oak API
> and the MicroKernel, ideally either as an extension point in the Tree
> or NodeState implementations. Additionally, to make sure that the
> implementation won't interfere with the performance of normal content
> access, this mechanism should probably only be invoked _after_ an
> attempt to access normal content has been made. Apart from these
> general ideas I don't yet have a good picture of what the detailed
> implementation could or should look like.
>
> Like with custom indexes, the configuration settings for such virtual
> content should in my mind go into the repository as normal content.
> For example, the following hypothetical repository tree would define a
> workspace subtree with a view to a shared /jcr:system subtree and a
> custom view for the latest 100 nodes in /latest:
>
>     /
>         /jcr:system {the global jcr:system tree}
>             /... {namespace & node type registries, version store, etc.}
>         /my-workspace [jcr:mixinTypes = oak:virtual]
>             /oak:virtual
>                 /system [jcr:mixinType = oak:mount,
>                          globalPath = /jcr:system,
>                          mountName = jcr:system]
>             /latest [jcr:mixinTypes = oak:virtual]
>                 /oak:virtual
>                     /view [jcr:mixinType = oak:view,
>                            query = "SELECT * FROM [nt:base] ...
>                                     ORDER BY [jcr:created] DESC LIMIT 100"]
>
> As before, please share your critiques, improvements and/or alternatives.

This is similar to what we did for exposing faceted navigation in the
Hippo repository. We defined some nodetypes to be virtual providers.
Whenever a nodetype is found for which a virtual providers is present,
that virtual provider kicks in.

For faceted navigation, we configure some node of type
hippofacnav:navigation that contains quite some configuration options.
To be able to do efficient faceted navigation, you on beforehand
however need to do custom indexing on properties (for example index a
date as a set of fields with different granularity). For an example of
what we support as configuration (mainly json like script) see [1]

We do *not* support virtual nodes intertwined or mixed with real
nodes. Thus, below the faceted node, everything is virtual.

A big hack we needed to make, was that if you configure a node that
would for example expose virtual nodes below it, it would only do so
after it has been persisted. This had the downside that it, and also
the jcr spec doesn't supply anything for it, would almost be
impossible to 'inject' free user queries in the faceted navigation
node (the free query would work as extra filter). Therefor, we misuse
the [] in jcr to support free searches. For example our paths support
/documents/content/faceted[{'apache'}] where 'apache' would be the
free text search. The argument in the [] can also be an entire xpath
query, also see at the bottom of [1]

Regards Ard

[1] http://www.onehippo.org/7_7/library/concepts/faceted-navigation/faceted-navigation-configuration.html

>
> BR,
>
> Jukka Zitting



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

Mime
View raw message