[
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)
