Hi, On 3/19/10 2:43 AM, Carsten Ziegeler wrote: > Hi, > > Justin Edelson wrote >> Hi, >> >> This is a longish email which I wrote in bursts over a few hours, so I >> apologize in advance if it's not completely coherent. Basically, I think >> we should do both... allow for the request's workspace to be used for >> script resolution AND provide the ability to mount non-default >> workspaces under the resource tree (i.e. /security -> the root node of >> the security workspace). > yes, seems to make sense. Fantastic. I'll start with the former :)
>> To my mind, at present Sling's resource tree is composed of a JCR >> workspace with 0 or more resource providers layered on top of the >> workspace's node tree (bundle, fs, etc.). For the purpose of the use >> cases I described yesterday, I am talking about replacing the base layer >> of the resource tree. We allow this today, it just doesn't work for >> script resolution (because of the specific need in script resolution to >> use a different session). > yes, but it's not just the session but also the path collision - the > same script path in different workspaces. That's OK. If the same script path exists in different workspaces, my point is that you should get the script that is the in the same workspace as that which was used for resource resolution. To be clear, I'm not contemplating having SlingScriptResolver discover scripts across workspaces and then rank them - the ranking needs to be local to a workspace. ... >> There is now no way to properly serve scripts from v1 anymore (AFAICT). > Ok, I think I got your use case now better :) Superb. ... >> >> Finally, it's worth noting that mounting additional workspaces under the >> resource tree doesn't obviate the need for initial content loading and >> observation/event support across multiple workspaces. In fact, it makes >> the latter more complicated in that JCRResourceListener now needs to map >> a path in a non-default workspace to an absolute resource path. I would >> be surprised if JCRResourceListener was the only place we assumed that >> JCR path == resource path. > In fact the listener does not assume this :) It's already prepared to > handle the case where the jcr is not mounted at / (but I haven't tested > it yet). Ah, you're right. But this option is not used anywhere. > Now, the assumption jcr path == resource path can't be guaranteed by > Sling. But it does look like there is an assumption that a jcr path can be transformed into a resource path in an consistent manner. This means that the mounting of workspaces inside the resource tree has to be static. Not sure if this is a problem or not. ... > After thinking about this a little bit more I had another idea which I > haven't thought through until the end, but I think it's worth sharing it :) > What about adding the workspace if it is not the default workspace to > the resource path, so in your cases, resource getPath returns something > like v1:/content/index, v2:/content/index or just /content/index. > We can add support for such paths in the resource resolver. If we're going to do that, why not just: resource.getWorkspace() ? I'm going to go ahead and commit my modifications. They should be entirely backwards-compatible and it seems like we have some consensus that, although there may be other needs, this is a reasonable enough place to start. BTW, after working with SlingScriptResolver in depth, I'm really interested to see that get cut over to ResourceResolverFactory :) Thanks, Justin > > And this information can be easily picked up by the script resolution > and handled accordingly. > > There should only be a few places where we need to add handling of these > new paths. And if people are not working with workspaces everything > stays the same. > > Again, just a rough idea.... > > Carsten
