Justin Edelson wrote > > I should also say that I had the (faulty) assumption that I would be able to > discuss this multi-workspace stuff face to face with some other Sling devs > at OSGi DevCon [Karl - I enjoyed drinking with you, but this didn't really > seem to be an area of interest :)]. Believe me, having a drink with Karl is more interesting than discussing this stuff with some Sling devs like me:) And yes, I wish I could have attended the OSGi DevCon :(
>> So I think have to change this, adding the workspace to the path >> property (if it is not the default workspace) would do the trick. >> > Wouldn't this break existing event handlers? If an event handler expects the > path to be a resource/jcr path, and it gets test:/foo/bar (workspace = test, > path = /foo/bar), the event handler will fail. No, I don't think this would break existing event handlers (or maybe not directly...) - now usually event handlers are interested in changes in some areas of the resource tree, like /mycontent etc. If the workspace is prefixed with a colon /mycontent does not match test:/mycontent and everything is fine. The problematic part is, when a event handler puts the path blindly into the resource resolver and tries to get the resource, then obviously the path could not be resolved - but that might be the same with the special workspace property. > > What might be interesting (haven't yet finished my first cup of coffee > today) is to add a new property to the event which contains a URI, e.g. > resource://test/foo/bar, deprecate the path property, and then migrate event > listeners to rely on this new uri property. Hmm ok, where is the difference between the uri and the path property, which means where do you put the workspace info in the uri? I think path should be sufficient as we are using the path all over the place. A Resource.getPath() should return an identical resource when the result is put into the resource resolver. Regards Carsten -- Carsten Ziegeler [email protected]
