For me one of the most interesting filters for "native" filtering would be
based on ResourceType (& RT changes). Optimally we would even have the
option to filter by ResourceType and its SubTypes - but detecting the
subtypes is something that would go beyond a hint (basically preprocessing
a hint to "unfold" it into all of the subtypes to watch out for).

I guess within the ResourceTypes the best practice would go into the
direction of SubTyping whenever the group covered is too generic and needs
to be treated differently.


On Sat, Oct 15, 2016 at 8:54 AM, Carsten Ziegeler <>

> Chetan Mehrotra wrote
> > On Thu, Oct 13, 2016 at 6:18 PM, Carsten Ziegeler <>
> wrote:
> >> The listeners we have are really just interested in paths
> >
> > Path is one aspect. There must be other aspect like change in specific
> > property name like sling:alias etc.
> >
> I think the most expensive one at the moment is the MapEntries listener
> in resource resolver which checks for vanity path and alias properties.
> So this is listening on add/remove/change of those properties.
> The other use case is where a listener is interested in a resource type
> - but that can't be done on Oak level as you would need to know the
> resource type hierarchy and other logic to detect the resource type.
> So, if we want to do this, we might add a hint for property names.
> I wouldn't go with a general filter string, like LDAP filter - as this
> creates problems on both sides: these filters are not rocket science but
> it's a little bit hard to write them, especially if they get long. And a
> provider implementation needs to parse and handle them.
> I would rather go with a "property names filter hint" - and if we detect
> other use cases we add another property for that.
>  Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland

Reply via email to