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):
/a:123
/a/b:456
/a/b/c:789
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:
/a:123
/a/x:456
/a/x/c:789
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:
/a:123
/a/x
/a/x/c
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).
Thanks,
Lars.
[1] http://www.day.com/specs/jcr/2.0/index.html
On Fri, Mar 22, 2013 at 3:44 PM, Lars Janssen <lars-listm...@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#3.7.14.3%20nt:childNodeDefinition
>
>
