You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2014/04/04 11:08:11 UTC
[jira] [Closed] (SLING-3350) Simplify Feature Flags API
[ https://issues.apache.org/jira/browse/SLING-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed SLING-3350.
-----------------------------------
> Simplify Feature Flags API
> --------------------------
>
> Key: SLING-3350
> URL: https://issues.apache.org/jira/browse/SLING-3350
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Feature Flags 1.0.0
>
> Attachments: SLING-3350.patch
>
>
> The Feature Flags API currently is quite complex involving a helper object making query for FeatureFlag status quite complex. Also, setting the current context is clumsy with (currently) two filters.
> I propose a few changes:
> (a) Remove ClientContext object. Checking for feature enablement should be as simple as just calling "Features.isEnabled(featureName)". Currently the curent ClientContext has to be retrieved and then the isEnabled method being called there.
> (b) Feature flag values are egerly evaluated. This should be done on demand making the context setup much quicker and light-weight. For added performance the evaluation results can still be cached.
> (c) The duplicate filter can be removed by code directly grabbing the ResourceResolver from the request attribute just like the SlingMainServlet does (thanks CarstenZ for the hint).
> (d) We don't currently need the explicit "context" management because the servlet filter does that directly using internal API.
> (e) I wonder, whether we need all these feature accessors in the Features service, some look like convenience methods, particularly the one of getFeatureNames and getFeatures.
--
This message was sent by Atlassian JIRA
(v6.2#6252)