Hi Betrand, I fear it is not as easy since this mandates rendering engines to be able to perform that filtering (in other words - to be able to skip rendering based on the feature flag) or we would require developers to utilize filters which are way more intrusive then a Resource Access Gate and could potentially do much more harm. Additionally this code needs to be applied to each consumer. This might not be that much work if applying features in the first place, but just think of a solution like AEM where a huge codebase should be "featurized" (e.g. a part should be deactivable due to licencing or some other criteria): each and every part of the application depending on a contentstructure would need to "learn" this new concept instead of filtering the resourcetree in first place.
If I got the idea of featureflags right they should be at least invasive in code as possible, keeping the risk low that a deactivated feature by accident influences the rest of the system at all. >From a consumers perspective I would like to be able to declare resources to be part of a feature (whitelisting) and probably to be removed for a feature (blacklisting - although this requires a logic resolving potential theoretical conflicts with a whitelist) by adding attributes. This attribute check must be implemented in a cheap way (not much more then already done during resource resolution process). Best regards Dominik On Mon, Jun 16, 2014 at 9:58 AM, Bertrand Delacretaz <[email protected] > wrote: > Hi, > > On Tue, Jun 10, 2014 at 2:53 PM, Dominik Süß <[email protected]> > wrote: > > -... Currently writing frontend that needs to adapt to featureflags > requires > > adding custom code to check and filter the ui to be rendered. This leads > to > > a lot of boilerplate code written over and over again with minor > differences... > > Can't that be solved by a utility library? Maybe with minimal changes > to the Sling core, but without baking feature flags into the core. > > -Bertrand >
