Hi Tommaso, On Wed, Nov 13, 2013 at 11:01 AM, Tommaso Teofili <tommaso.teof...@gmail.com> wrote: > ...I agree it'd be nice to enable feature flags also on the resource (even if > I'm not too much convinced access gates are a good fit for it) and service > level, and design the API for that too....
I thought about that (and Robert has a similar question above) and I'm not sure what the best option is. We might go for three isEnabled methods: isEnabled(T featureFlagID, SlingHttpServletRequest request) isEnabled(T featureFlagID, Resource resource) isEnabled(T featureFlagID) But that means all FeatureFlagsProviders need to implement all three methods, and some of them might not be relevant. Or create three provider interfaces, one for each signature above, and the FeatureFlags service sorts the providers according to which interfaces they implement. Another option is /** @param context can be null */ isEnabled(T featureFlagID, Object context) Which requires FeatureFlagsProviders to use downcasting, not fantastic either. I agree with the need for feature flag providers to react to different types of contexts, not sure how to implement that...any suggestions? -Bertrand
