jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Janssen <lars-listm...@ukmix.net>
Subject Preview workflow based on workspace clone/node update
Date Fri, 22 Mar 2013 15:44:19 GMT
Hi all,

Does anyone have any experience of using Workspace->clone() and
Node->update() to implement a preview capability? I'm looking at the
feasibility of establishing the following workflow for a CMS using
Jackrabbit:

1. Two workspaces, e.g. "preview" and "published".
2. Users make all their edits in the "preview" workspace.
3. To publish a new document, the node is cloned to the "published"
workspace.
4. To change a document, user first edits in the "preview" workspace. To
publish the change, we call the Node->update() method on that document's
node.

So far, so good, but the documents don't exist in isolation. We have two
types of document, "page" and "block" (both using node type nt:unstructured
at the moment).

A page can contain blocks OR pages, a block can only contain other blocks.
Here is the simplest possible example, showing the node paths:

/page1/
/page1/block1
/page1/subpage1

In our user interface, we will allow the user to edit page1 and block1
together (e.g. page1 might include the page title, and block 1 a block of
text for the page body).

My concern is what happens when we call the update method on page1. From
looking at the JCR 2.0 spec[1] and trying some working examples, it looks
like the node "/page1/subpage1" will also be updated. This could have
performance implications on larger trees, but it also has a workflow
implication: there might be changes on subpage1 that are not ready to be
published.

I can imagine a solution similar to "jcr:onParentVersion copy"[2] whereby
we could somehow control the update cascade (it might require us to use
different node types for blocks and pages of course), although I don't
think any such thing exists yet.

I guess we could also do a work-around at the application level, to copy
(merge?) the nodes over individually, but this would negate the benefit of
having the clone/update mechanism available, at least for this use case.

Is there a way to achieve this roughly as described, or a completely
different approach that's recommended?

Many thanks,

Lars.

[1]
http://www.day.com/specs/jcr/2.0/10_Writing.html#10.8.3%20Updating%20Nodes%20Across%20Workspaces
[2]
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.14.3%20nt:childNodeDefinition

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message