Can we get some consensus, whether we need to specify that a resource is hidden if a feature is enabled?
The use case I heard of, is that e.g. a button/link(navigation entry is switched depending whether the feature is available. If it's available button A is rendered, if not button B - this could be easily done with two resources, one enabled for the feature and the other one disabled. But if there are other, easier ways of doing this, I'm fine as well Thanks Carsten 2014/1/20 Carsten Ziegeler <[email protected]> > I'm fine with using OR and not going up the hierarchy to see whether a > parent is hidden. > > Carsten > > > 2014/1/20 Bertrand Delacretaz <[email protected]> > >> Hi, >> >> On Mon, Jan 20, 2014 at 9:35 AM, Felix Meschberger <[email protected]> >> wrote: >> > Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <[email protected]>: >> >>... It seems we have use cases, like A-B testing where you want to hide >> a >> >> resource if a feature is enabled.. >> >> ...We can easily implement this with negating the value, like >> >> !featureX as a single string property value... >> >> Agreed, but isn't -featureX more readable? We are using - already to >> negate tags when selecting health checks for example, not sure if we >> are already using ! in other places at the user level. >> >> > ...So to do A-B testing in this case your resources will have to be one >> in front of >> > another in the virtual candidate list and the feature flag on the first >> indicating whether >> > to accept it or not.... >> >> And how do you "put a resource in front of the other" ? Doesn't seem >> convenient to me, the -featureX syntax is simple and unsurprising. >> >> > >> > ...I think we should come up with really concrete requirements and >> implementation proposals >> > to be able to discuss this further... >> >> We do have use cases at >> >> https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support >> , >> this one is "alternate between resources based on feature flags". >> >> As for the implementation, adding support for negated feature names in >> ResourceResolverContext.applyFeatures() in your current whiteboard >> prototype looks trivial. >> >> >> Now, how do we treat a multi value for sling:features, like >> ["featureA", >> >> "featureB"]? Is this resource visible if both features are active >> (AND) or >> >> if at least one of the two is active (OR)?... >> >> Like Felix I think using OR here is the simplest, if someone needs AND >> they can always implement a Feature that's a composite of others. >> >> If you then have sling:features = "A, -B, C" the resource is visible >> if feature A is enabled OR feature B is disabled OR feature C is >> enabled, that's clear IMO. >> >> I also agree with leaving feature tree inheritance for later, that >> shouldn't have impact on APIs, it's only an implementation change. >> >> -Bertrand >> > > > > -- > Carsten Ziegeler > [email protected] > -- Carsten Ziegeler [email protected]
