Chetan Mehrotra wrote > Oak would be collecting the name of the properties (OAK-4907) which > got changed in a given commit and that can be used for filtering. This > I think should help the MapEntries case and probably the resourceType > case also. They can just hint for those property names and then > listener would only be called if there is some change in those > properties > >> I would rather go with a "property names filter hint" - and if we detect > other use cases we add another property for that. > > Makes sense. This would keep things simple and precise
I plan to release API early this week :) So it would be great if we could get this in, or we move it to the next api release. > >> Yes, and as mentioned a check based on a resource type is not that easy, > > Can you provide some details on what kind of change the impl is > interested in. Is it change in the value of resourceType property? Any > pseudo code of the kind of logic that listener would be performing. > That would help in determining if we can make this case faster > The code is usually interested in the change of a resource of a specific type, for example, if a page is added, removed or changed. This does not mean that the sling:resourceType property changed, but something else on that node. In addition that node could have a resourceType property set to myapp:MyPage which inherits through five levels from sling:Page (let's assume it would exist) and the listener would be registered for being interested in sling:Page. The logic to calculate the resource type hierarchy is quiet complex and requires access to a resource resolver to do so as potentially several resources in the resource tree must be traversed to get the result. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org