Hi Felix and Tobias,
thanks for your answers! I'm taking this to [EMAIL PROTECTED] since it's
quite OT for Sling.
-- Andreas
Tobias Bocanegra schrieb:
On 6/27/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hi Andreas,
I also consider the "separate workspaces" approach best. In particular it
lends hand to an extended solution if you decide to complete separate author
and staging, where you have two distinct repositories and replicate data
from author to staging.
Access Control handling depends on the JCR repository implementation.
JSR-170 (JCR 1.0) does not have any standardized ACL (except a single call
to check for access). JSR-283 (JCR 2.0) will bring standardized ACL. Still,
how this is implemented remains - of course - unspecified.
IIRC the approach taken in Jackrabbit is to attach ACL child nodes to the
nodes to which access control is applied. So if you replicate (workspace
update, cross-repository replication) any node (or subtree) and include the
ACL child nodes in the replication, you get the same access control on both
sides.
in an upcomming version of jackrabbit that will implement some
features of the to-be-released JSR283 spec, there will also be a
user-based hierarchical access control. this usually suits better for
CMS application, since CMS authors are usually authorized to maintain
one subtree of the site.
that hierarchical user-based ACLs will be stored per-workspace, i.e.
if copying a node to another workspace, the same user can have
different ACLs. This makes sense, since a content author might not be
allowed to alter content on the staging or even the live workspace.
with a document-based ACLs you would need to remove/alter them
'manually' when copying them to another workspace. however, this might
not be a big problem, if you define some ACLs on the respective parent
nodes, because the privileges get inherited to the child nodes.
regards, toby
For the workspace update mechanism, you don't have to care for the user
setup as users are stored repository-wide in the system workspace. For a
cross-repository replication you have to take care that the user base
matches on both repositories, of course.
Hope this helps.
Regards
Felix
Andreas Hartmann schrieb:
Hi Felix,
> Andreas Hartmann schrieb:
>> is it possible to access multiple JCR workspaces via a
>> Sling application?
>
> Basically yes. Your application may grab the Repository (or
> SlingRepository) service from the service registry and login to the
> repository specifying different workspaces to access.
thanks for your answer, it's good to know that accessing multiple
workspaces is possible.
I'd be interested in your opinions about the correct approach to a staging
environment like it is provided by traditional CMS applications. I see the
following options:
Separate workspaces
===================
* Corresponding nodes with same UUID possible
* Updating nodes/subtrees possible
* Question: How are access control settings handled?
Separate areas in a single workspace
====================================
* No corresponding nodes with same UUID possible
* Maintaining access control definitions could be complicated
* Updating nodes/subtrees has to be implemented
Separate areas as child nodes
=============================
* Areas not self-contained
* No direct URI-to-path mapping possible
Labelled versions
=================
* Changes applied immediately, without calling Session.save()
(might be a problem wrt transactions)
* Access control to version history has to be considered
My gut feeling tells me that separate workspaces are the most promising
approach. But I don't know how the access control settings (in this case,
permissions to change properties of particular nodes) are maintained across
workspaces. Would they have to be kept in sync manually?
Is there a general best practise to model this kind of functionality?
Thanks a lot in advance for any hints!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
