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 >
