Hi Bertrand, the UI of an application based on Sling are often composed of existing resourceTypes so you cannot just decide in the code to display or not to display so you have to "annotate"/"flag" the resources and then have some code deciding if this resource should be rendered or not. For sure you could add code to each resource to check if it is to be rendered but this is a lot of repetive code. Another option would be a Servlet filter to skip inclusion at that Point. But this all fails in some situations like whenyou consume an aggregated json dump and use this on client side. Therefore the only shared location that all code should act on when looking at the persistance is the resourcetree, and as already existing API the Access Gate API seems to be capable of doing exactly what is required - masking the resourcetree based on custom logic.
Best regards Dominik On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz < bdelacre...@apache.org> wrote: > Hi Dominik, > > On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <dominik.su...@gmail.com> > wrote: > > ...as far as I can see the API is just covering the java aspect of > this... > > Nothing prevents you from using the FeatureFlags service in scripted code. > > > ....you could have a gate looking for a marker at a resource > > which indicates it to be part of a specific feature and therefore > disables > > access to it.... > > Do we need any changes to Sling or to this new API to enable that? > > The problem IMO is that this makes the whole thing less transparent > than using feature flags in the rendering code. OTOH if people can > implement it themselves (and add the corresponding info to > RequestProgressTracker) for transparency, I don't mind. > > -Bertrand >
