Thanks Felix, yeah now I see the light (and I really mean it this way) - so far I got this feature stuff totally wrong and rather focused on hiding resources if a feature is enabled - which doesn't make that much sense....
So I guess we have to recap the whole feature api - and I also think that implementation wise it would be better to directly do this in the resource resolver implementation. This way we can have a better and potentially more performant implementation. Carsten 2014/1/17 Felix Meschberger <[email protected]> > Hi > > Hmm, I will have to read that stuff again, but I fear we are building an > elephant instead of a mouse here … > > A Feature Flag will enable a feature if the flag is set. As a consequence, > since a flag in general is *not* set by default, the corresponding feature > is disabled by default. > > Am 17.01.2014 um 11:54 schrieb Carsten Ziegeler <[email protected]>: > > > Hi, > > > > the current implementation (and API) of our feature flags is "optimized" > > for what I call the negative case, which means if a feature is enabled, > it > > hides resources (negative = hiding). > > That is in fact wrong: Resources should actually be hidden, if the feature > is *not* enabled. If the feature is enabled, resources are hidden. > > > > > From some use cases, it seems that the positive case is very common: if a > > feature is enabled, resources a visible (positive = visible). And if the > > feature is not enabled, the resources are hidden. > > That *is* IMHO the one and only case for feature flags with respect to > resources. > > > > > So if you want to implement the negative case, your Feature returns true > > for isEnabled if the feature is really active. > > However, to implement the positive case, your Feature implementation > > currently should return true if it's not enabled and false otherwise. > Only > > with this logic, it's possible to hide resources if the feature is not > > enabled. > > This paragraph makes no sense at all (see above) > > Regards > Felix > > > > > So it's possible to do this and maybe we just have to document it > properly. > > > > WDYT? > > Carsten > > -- > > Carsten Ziegeler > > [email protected] > > -- Carsten Ziegeler [email protected]
