Hi Vidar, Vidar Ramdal schrieb: >> Vidar Ramdal schrieb: >>> 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. > > On Tue, Nov 11, 2008 at 2:49 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> 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". > > Exactly, that would be what I want. (Or even better, the draft > workspace would be mapped to requests with extension/selector = > ".draft", but I guess that's more complicated). > So you can consider this a vote (+1) for your proposal, if I'm allowed > to vote :)
Yes, everyone is allowed to vote. Yet there are votes (release votes mostly), where some votes are binding and some are not. In fact I consider it a good thing to get a broad range of votes, not only "binding" ones, because non-binding votes are kind of a signal of interest. > >> [...] >> 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. > > Hmm, hadn't thought of that solution. But when you say implement a > ResourceProvider for /apps, would it be possible to implement a > ResourceProvider for the "draft" workspace instead? Sure, the problem is then how to get the credentials into your ResourceProvider. In addition you are faced with another issue with the current definition of the ResourceProvider interface: This is currently global and does not know the concept of users etc. To implement your use case, you might want to go for a Facade Implementation, where the Facade is registered and hands over the method call to a real instance, which might be thread (or request) -bound to support per-user differences. > > In either case, what (in your opinion) would be the easiest approach > to implement the ResourceProvider? Extending JcrResourceProvider, or > creating one from scratch, or something completely different? > > I would assume that starting from the existing JcrResourceProvider is probably a good idea because this one already contains most of the core code required. You just need some integration glue to get it running, probably. Hope this helps Regards Felix
