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]
