If no one complains I'll move this stuff into the contrib section - we can change it there anyway
Thanks Carsten 2013/12/19 Carsten Ziegeler <[email protected]> > Hi Amit > > thanks for the feedback - yes, good point with active vs available. I'll > change that. > > Yes, as the implementation manages the contexts, it first calls isEnabled > on the providers to know which features are enabled and then only calls the > other methos like hideResource if the feature is really enabled. This > avoids double checking. I'll make some updates to the javadocs > > Thanks > Carsten > > > > > 2013/12/19 Amit.. Gupta. <[email protected]> > > Hi Carsten, >> >> In FeatureManager >> String[] getFeatureNames(); >> >> Javadoc says it returns all active features. Active might give an >> impression of this only returning enabled features, but rather it returns >> all available features. Changing the javadoc will also align with >> FeatureManager.isAvailable. >> >> And, I could not understand how context is passed on in >> FeatureManager.hideResource(final String featureName, final Resource >> resource) >> >> Is it the caller's responsibility to first check isEnabled(featureName, >> context), before calling hideResource? >> >> Thanks, >> -Amit >> >> -----Original Message----- >> From: Carsten Ziegeler [mailto:[email protected]] >> Sent: 19 December 2013 10:33 >> To: [email protected] >> Subject: [RT] New Feature Flags API / Impl >> >> Hi, >> >> I've started with a new approach to implement the feature flags - the >> focus is on the API, which means what features do our feature flags have >> and how can they report it. (The implementation should be functional but I >> haven't checked it yet). >> I went back and forth with different approaches based on Bertrands >> prototype and all the discussions and I think this approach is the most >> promising one: >> >> The central service for client code is the Features service: >> public interface Features { >> >> String[] getFeatureNames(); >> >> boolean isAvailable(String featureName); >> >> ClientContext createClientContext(ResourceResolver resolver); >> ClientContext createClientContext(SlingHttpServletRequest request); >> >> ClientContext getCurrentClientContext(); >> >> } >> >> This can be used to find out which features are available and to create a >> client context - the context is either based on a request or on a resource >> resolver. >> The client context in turn can be used to find out whether a feature is >> enabled: >> public interface ClientContext { >> >> boolean isEnabled(String featureName); >> >> Collection<String> getEnabledFeatures(); } >> >> So a script can use this, to do things differently etc. >> In addition the Features services provides the "current client context" >> which is automatically available for a request. >> >> Now, somehow we need an API to define which feature is available and what >> it does - I came up with an extended version of the FeatureProvider (and >> I'm not so sure about this one): >> public interface FeatureProvider { >> >> String [] getFeatureNames(); >> >> boolean isEnabled(String featureName, ProviderContext context); >> >> Map<String, String> getResourceTypeMapping(String featureName); >> >> boolean hideResource(String featureName, Resource resource); } It's >> similar to the Bertrand's version, except that it takes a ProviderContext >> (which allows access to the request and resource resolver) and has two >> additional methods control the two most wanted features: hiding resources >> and changing of resource types. >> >> We could then implement this provider reading OSGi configurations or >> whatever to define features. >> >> All constructive feedback welcome - and as I said, let's first define the >> API >> >> Everything can be found at: >> http://svn.apache.org/repos/asf/sling/whiteboard/feature-flags/ >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> [email protected] >> > > > > -- > Carsten Ziegeler > [email protected] > -- Carsten Ziegeler [email protected]
