Hi Bertrand, I'm not really about altering resource rendering but enable disable resources for rendering, so I probably wouldn't decorate the scripts and servlets but the resources that define those resourceTypes. This is what we all have done a lot when hiding away frontend for endusers (at least I know nobody who didn't have to do that once in a while) via ACLs wherever the UI was composed from resources.
I get the case where you would like to alter the Script/Servlet that handles a resourceType but as you mentioned this comes with quite some constraints and locations that would require some changes to work. To get this working we would definitively need some script metadata which could also be added as annotation to be able to distinct on servletresolution. I do not like the term "magic feature flags" since it implies there would happen something out of control for a developert. "Declarative feature flags" is matching what I'm thinking of - declaring something being part of a feature and having a unified behavior of the system to handle these for the specific cases just as we have a declarative way of defining selectorbased filtering for scripts and/or servlets (declaration syntax is different but declaration and behavior of the system is always the same. IMHO we should go for the simplest mechanism first - which is the "endresource" being declared being part of a specific feature and carefully checking the lower level mechanisms for alter resource rendering. It still is better to have an easy and cheap solution that covers the easy cases but requires some engineering where more complex scenarios come into the game then forcing people to write custom code everywhere even for such common cases like disabling a Tab in a ui. Best regards Dominik On Mon, Jun 16, 2014 at 3:13 PM, Bertrand Delacretaz <bdelacre...@apache.org > wrote: > Hi Dominik, > > On Mon, Jun 16, 2014 at 1:55 PM, Dominik Süß <dominik.su...@gmail.com> > wrote: > > ...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)... > > so IIUC you're looking at the "alter resource rendering" use case of [1] ? > > Note that even if the resource resolver hides rendering resources like > scripts, I suspect you'll get in trouble as rendering scripts are > cached. That's a good example of why I pushed for the SLING-3483 > removal. > > > ...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)... > > I sense a slightly more complex use case than [1] here...not sure if > in-content feature flags are the right way to implement this. > > >... 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.... > > aka "magic feature flags" ;-) > > I agree that this looks nice, but as mentioned before I'm wary of > multiple weird side effects like the caching thing mentioned above. > We've seen those coming before SLING-3483, and so far no one has been > able to reassure me that we're not opening a can of worms. > > > ...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... > > Assuming you want to work like this for scripts, how to you handle > rendering servlets? > > -Bertrand > > [1] > https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support > > P.S. no emotions about this on my side...I'm just not convinced so > far, and wary of possible side effects. Best way to convince me is > probably a prototype with sufficiently good tests that prove me wrong. >
