On 3/19/10 2:59 AM, David Nuescheler wrote:
> I just saw the topic of this thread and thought i would like to weigh in on
> this conversation...
I think the subject of this thread is slightly misleading... it really
should be "scripts should be resolved from the same workspace as
resources". Which is essentially the summary of SLING-1446.
> Workspaces are just about one of the most frequently abused feature
> of JCR and I have a feeling that this thread may forget what workspaces
> are for.
Nope. The specific use cases I posted were in line with, uh, your model.
At least I think they are.
> Workspaces are for .clone(), .merge() and .update() [1]
>
> They are not for separating things out, like user A has a workspace
> and user B has
> a workspace, they are also not for separation by type.
I have to stop you there. user-specific workspaces seem like a perfectly
legitimiate use of workspaces IF those users are editing the same
content tree.
Imagine four workspaces:
1) user1
2) user2
3) trunk
4) publish
A node is created in user1 at /content/index, then clone() is called in
trunk [i.e. clone("user1", "/content/index", "/content/index", false)].
The node is then cloned into user2 [i.e. clone("trunk",
"/content/index", "/content/index", false)]. User2 makes some changes in
their workspace, saves, and then updates the node in trunk
[node.update("user2")]. Finally, the node is clone from trunk to publish
and is user-facing.
The key point I've understood about workspaces and their appropriate use
is that workspaces are supposed to represent the same content tree.
Having private working copies doesn't seem to violate this.
> Usually when people use workspaces without using merge, clone or update they
> usually want to either use Access Control and the hierarchy or
> separate repositories.
> Workspaces are not a good solution for either of the two.
By the by, something to consider for JCR 3 is that clone/update/merge
all operate from the perspective of the "target" workspace (i.e. the
workspace being cloned into, updated, merged). For promotion workflows,
I believe corresponding methods called from the source workspace/session
would be more natural, similar to how "git push" works.
Justin
>
> regards,
> david
>
> [1]
> http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.
