Sorry it's taken me a few days to get back to this... On Wed, Mar 24, 2010 at 10:55 AM, Carsten Ziegeler <[email protected]>wrote:
> > >> 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. > I was more thinking about cases where one assumed that the first character in the path is a "/", but now that I think of it, this is probably less-than-common. It is worth noting that if you are using workspaces correctly (at least according to David's Model), then you are likely interested in the same area of the resource tree in every workspace. This is the case, for example, with the script resolver (which is where the need to implement cross-workspace events comes from). > > > > > 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? > The difference to me is that URIs tend to be more formalized and it allows us in this case to make a clean break and not overload an event property which already has meaning. I could even imagine saying that events from non-default workspaces don't even have the path property, just the URI property. I'm thinking resource://[workspace][path] as the syntax (sorry if this wasn't clear). > 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. > So are you suggesting that the resource resolver resolve [workspace]:[path] and that Resource.getPath() return this form for non-default workspaces? Justin > > Regards > Carsten > -- > Carsten Ziegeler > [email protected] >
