Hi Am 20.01.2014 um 04:19 schrieb Carsten Ziegeler <cziege...@apache.org>:
> If the sling:features property contains a single string value, this > resource is only visible if the feature is enabled. This is pretty straight > forward. Yes > It seems we have use cases, like A-B testing where you want to hide a > resource if a feature is enabled, so A is enabled and B is hidden if the > feature is active, and A is hidden but B is active if the feature is not > active. We can easily implement this with negating the value, like > !featureX as a single string property value. I do not really understand … With feature flag support in the resource resolver we essentially control whether a candidate resource is selected to be resolved or got. The first resource found that can be used is returned. "Can be used" means, it is readable and either has no feature flag or the named feature is enabled. 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. I think we should come up with really concrete requirements and implementation proposals to be able to discuss this further. For now, I would prefer to not go down this route and keep it simple. > > 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)? > And it gets very interesting if at least one value is negated, like > ["featureA", "!featureB", "featureC"] ? Well, my current implementation says: a resource is visible if at least one of the named features is enabled. In this sense it is featureA OR featureB OR featureC. There is no negation and no AND. I would think that more complicated logic to select resources should actually involve real scripted (or servlet) logic where two (A-B) or more (A-B-C-…) resources are known and can be chosen and then <sling:include>-ed > > And while we're at it, is it possible to hide a hole tree? So if I have a > content tree with many child nodes at /foo and add a sling:features > property to the root node foo, is the whole sub tree hidden if the feature > is not active? It is currently hidding if you drill down the tree going from get(/foo) to listChildren. A descendant resource /foo/some/where/inside is not hidden. As such the feature flag does not currently have a hierarchic consequence. I could think that we might to want it to have a hierarchic consequence with more consequences on performance on asking on how to "remove" the feature flag down the tree again. Maybe for now, don't do this. Regards Felix > > Regards > Carsten > -- > Carsten Ziegeler > cziege...@apache.org
