Hi Agreed: Sling should come with a support for Feature-based resource filtering (or however we call that mechanism) and it should be on the same level (contrib or bundles) as the Features feature itself.
Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 15.11.2013 um 00:11 schrieb Dominik Süß <dominik.su...@gmail.com>: > Hi Bertrand, > > I disagree on that one - maybe we should put it in contrib or so, but is is > essential to disable most features to disable some parts of the > resourcetree. This is just applying your api in a conventient api to > resource resolving. There is no additional magic since developers would > have to set the flag in the content anyways. > As mentioned earlier the majority of features I have implemented yet do > have a frontendpart that would get rendered and it would add additional > complexity if I have to use custom resourceTypes (inherited ones through > superType) just to disable them based on such rules. > > Best regards > Dominik > > > On Thu, Nov 14, 2013 at 2:03 PM, Bertrand Delacretaz <bdelacre...@apache.org >> wrote: > >> On Thu, Nov 14, 2013 at 1:56 PM, Mike Müller <mike...@mysign.ch> wrote: >>> ...Just implement a >>> FeatureFlagResourceGate (or whatever name would make sense).. >> >> My earlier question was, can one do this without any changes to Sling >> besides providing a way to find if a given feature is enabled, like in >> my prototype? >> >> I think the answer is yes, and if is is I wouldn't worry about it - >> let users implement that themselves to start with, but don't put >> anything in Sling for now besides the raw FeatureFlags (or Feature) >> service. >> >> Then, if common use cases emerge that need something in Sling, >> implement that - but cross that bridge once we get there. >> >> -Bertrand >>
