jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Janssen <lars-listm...@ukmix.net>
Subject Re: Preview workflow based on workspace clone/node update
Date Mon, 22 Apr 2013 11:39:59 GMT
Hi all,

Sorry to bump my own topic, but I have also come across another aspect of
cloning behaviour that I didn't expect.

Let's say workspace 'preview' contains these nodes (all nt:unstructured
with mix:referenceable, shown here with the UUID):


When I clone /a into workspace 'published', it also has exactly the same
nodes and ids as above. This is as I expected.

Now let's make a change; rename node '/a/b' to '/a/x', so the 'preview'
workspace looks like this:


To publish my change, I get an instance of node /a in the 'published'
workspace, and call a->update("preview"). This successfully clones the
nodes, but some ids are missing:


The node that I changed, and all its child nodes, no longer have a uuid.
However, they still retain the type 'mix:referenceable' (which, if I
understand correctly, implies that they must have a uuid).

Is this a bug, or expected behaviour? I've referred again to the JCR 2.0
specification[1], especially sections 3 and 10 and appendix A.

Using Jackrabbit 2.6 via the DavEx interface (with PHP's
Jackalope-Jackrabbit connector).



[1] http://www.day.com/specs/jcr/2.0/index.html

On Fri, Mar 22, 2013 at 3:44 PM, Lars Janssen <lars-listmail@ukmix.net>wrote:

> 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#

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