Hi Bertrand, sure you could deliver a synthetic resource, but anyways you would have this resource in Resource.listChildren() - this is why I said that you then would need to make sure all your application code is aware of this possibility. The idea to keep the core free from additional code was the reason why I did think of access gates as an already existing hook that provides matching functionallity (filtering the resourcetree based on codable accessrules).
I still think it is important to have such support since most "features" coded in sling are "content"(/resource)-driven so a switch that just acts in the javacode will in my eyes not be sufficient to be usable. (I just had such a scenario in a project where we had a really hard time to setup the corresponding ACLs to activate and deactivate the feature by groupmemberships) Best regards Dominik On Fri, Nov 15, 2013 at 9:27 AM, Bertrand Delacretaz <[email protected] > wrote: > On Fri, Nov 15, 2013 at 7:51 AM, Dominik Süß <[email protected]> > wrote: > > Am 14.11.2013 23:11 schrieb "Alexander Klimetschek" <[email protected] > >: > >> ...And the ResourceDecorator can't filter out things? > > > > No, returning null skips tehe decoration and returns the original > resource. > > You could hide properties but you'd additionally have to handle such > > resources in applicationcode... > > Yes, the ResourceDecorator can supply a synthetic resource with a > resource type that points to a do-nothing renderer. > > The more we discuss this, the more I feel we don't need more than > something along the lines of my prototype, in the Sling core. > > Additional modules like a specialized access gate or resource > decorators in contrib are fine, but I'd like to keep the changes > minimal in core, as people will need time to figure exactly where and > how this is useful. > > -Bertrand >
