Hi Michael, On Wed, Jul 16, 2014 at 5:12 PM, Michael Dürig <mdue...@apache.org> wrote: > > Hi, > > What do people think about adding further filtering capabilities to > JackrabbitEventFilter? I was thinking of path exclusion and user data > exclusion: > > - Path exclusion would allow certain paths to be excluded from sending > events. This is helpful if you want to listen to say /content but not to > /content/foo. Relieving event handlers from handling such exclusions will > lower client code complexity and increase performance.
That sounds interesting. I don't think I've seen this in practice but I can imagine it being used. However I think that such exclusions are really based on more directly expressed criteria. Taking for example * /content is the pool of all content * /content/ugc contains users-generated content I know that /content/ugc is not interesting to my listener, so I can exclude it by path. However, the basis of the exclusion can be expressed more directly in the form of a property constraint, something like [jcr:primaryType=my:ugcNode]. In practice the filtering is a bit more complex, the condition would be: "Have a parent of type my:Page until - but excluding - /content". However, I'm not sure if this can be expressed concisely by a JackrabbitEventFilter or if the evaluation can be done is an efficient manner by Oak. > > - User data exclusions would allow for excluding events with certain user > data. This could be useful if a session wants to bulk write some data > without the respective event handlers being fired. That session would just > need to set the user data to the same value as specified in the exclusion > filter. What would be an example of user data? Property value constraints? Thanks, Robert
