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. <amitg...@adobe.com> > 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:cziege...@apache.org] > Sent: 19 December 2013 10:33 > To: dev@sling.apache.org > 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 > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
