+1 on extension hook in RR and adding this I had no closer look at Accessgate yet and thought it to behave that way from initial talks about this before implementation started. I just thought that Access Control is not just about permissions, it is about granting or denying access based on what ever logic you implement.
Best regards Dominik On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding <jsedd...@gmail.com> wrote: > > Rather I could imagine backing this into the ResourceResolver itself ... > > I think we should avoid going down this route. The ResourceResolver is > a core feature of Sling, while feature-flags is (should be) an > optional feature. > > Baking feature-flags into the RR would violate modularity IMO. > > One way to achieve the same integration without baking that > functionality into the RR would be to create an extension hook that > allows decorating the RR. Then the FF bundle could provide such a > decorator and filter resources according to its needs. > > Regards > Julian > > > On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger <fmesc...@adobe.com> > wrote: > > 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 > >>>>> > >>>>> > >>> > > >
