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
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 Ziegeler
Adobe Research Switzerland

Reply via email to