Hi I agree that it would be cool to also select resources based on features. But I think the access gate is the wrong mechanism: Access Control and Feature Selection are different beasts and should not be mixed.
Rather I could imagine backing this into the ResourceResolver itself: before returning a Resource it is checked for a feature flag property (e.g. sling:feature ?) and this being checked against the Feature service. If not enabled, that resource is „hidden“ and not returned. WDYT ? Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 14.11.2013 um 02:21 schrieb Dominik Süß <dominik.su...@gmail.com>: > Hi Ruben, > > the intention is to disable features that are not should not be globally > available but might be activated under certain conditions. This reduces the > need to branch non-production ready features away and merge them in later > and opens the option to have something like a "Friendly user Test" or > softlaunch of a feature. Therefore this can be something big or something > small. I think a solution should be capable of dealing with both. The java > API would allow to hook in at any granularity level of the application so > this already fullfills the requirements I'd have. Adding a corresponding > declarative logic to filter the resourcetree would give the same coarse > and/or finegrained filtermechanism to the resolutionprocess. > > What still would be missing is controlling updates and not just additions. > e.g. when a resource should be rendered by a new version of a resourceType > - in such case it might be an option to extend the searchpath from > /libs/../myresourcetype, /apps/../myresourcetype by featurespecific > overlaypaths that would either be searched when a feature is activated or > hidden if the feature is deactivated. This would require refactoring later > on but would allow parallel existance of multiple versions of a > resourceType. > > Best regards, > Dominik > > > > > On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser <r...@headwire.com> wrote: > >> Bertrand, Dominik, >> >> the feature flag may also have an impact on the nodes/properties that you >> need to render the feature. Being able to handle this in the resource tree >> directly without having to handle it in component code would be great. >> However, I am not sure if the intention of the feature flag was more to >> enable/change little features (code fragment) and not really change big >> things (leave that to test&target or other products?) >> >> Ruben >> >> >> On 11/13/2013 6:32 AM, Dominik Süß wrote: >> >>> 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 >>>> >>>> >>
