Hi Vidar,
Interestingly, your request seems to be supported by my proposal for the
ResourceResolverFactory [3]. In such a case, you would probably have two
ResourceProviderFactory services registered: One would support the
default workspace at "/" and the second one would support the draft
workspace at "/content".
Whenever a user logs into the system, the ResourceResolverFactory asks
the respective ResourceProviderFactory services for ResourceProvider
instances, which you could provide depending on the requested user and
any other detail provided by the AuthenticationHandler.
As an alternative -- short term -- approach, you might want to implement
a ResourceProvider - say - for the /apps tree, which just uses
SlingRepository.loginAdministrative() to login to the default workspace
as an administrative user and which would serve the /apps tree from there.
WDYT ?
Regards
Felix
Vidar Ramdal schrieb:
> Hello Slingers,
>
> We are developing an application which will feature a staging concept.
> That is, the user should be able to save and preview changes before
> publishing them to the world.
>
> We have read some previous posts with great interest, in particular
> [1]. In that thread, Felix Meschberger suggests [2] using multiple
> workspaces to achieve this. In our case, that would be a "draft"
> workspace in addition to the default workspace.
> (The proposition at [3] also seems interesting in this respect).
>
> As a temporary proof-of-concept, we've hacked
> SlingAuthenticationHandler to look for a "workspace" parameter in the
> URL, to decide which workspace to connect to:
> SlingAuthenticator#218:
> String workspace = req.getParameter("workspace");
> log.debug("authenticate: credentials, trying to get a session");
> Session session = getRepository().login(
> authInfo.getCredentials(), workspace /* was: null */);
>
> This way, we're able to access content in the "draft" workspace by
> http://localhost:8888/path/to/node?workspace=draft
>
> But having content stored in different workspaces introduces a number
> of difficulties. The first roadblock we've hit, is this:
>
> We want to render content in the "draft" workspace with scripts stored
> in the default workspace. Since only one JCR session is created per
> HTTP request, we're unable to access both a node in "draft" and the
> scripts stored under /apps in the default workspace. (Of course, we
> could duplicate all content under /apps to both workspaces, but that
> seems just ... wrong).
>
> Looking at the different interfaces in Sling, it seems it should be
> possible to implement a custom JcrResourceResolver. The Resolver would
> examine the HttpRequest, and create a connection to the desired
> workspace and fetch the content.
> Given that this is a possible solution, how do we register our
> JcrResourceResolver so that it can respond to certain requests? Or is
> this not a good solution at all?
>
> [1] http://markmail.org/message/4eh45utq72qf4eqo
> [2] http://markmail.org/message/utwgtv7z7rfx6jgl
> [3] http://markmail.org/message/fslkzj3dlkbn4lxo
>
