Hi Felix, see my comments inline.
Best regards Dominik On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger <[email protected]>wrote: > Hi > > Sure you can do it, but it (a) doesn’t match the idea of an access gate > (at least not in my little brain cells) and (b) it is not comprehensive > since the JCR Resource Provider does not leverage that. (b) is IMHO the one > reason breaking the idea. > Although I disagree on a (what else is this but restriction of access (don't mix it with permission by default) if b is the case (so it could not be granted to act on the global resource Tree I agree this would be a no go > I like the idea of a decoration hook. Yet: it might have to be implemented > somewhat differently because we don’t just want to have or have not a > resource. In some cases we want to fall back to a resource with a lower > „priority“ such as a resource furhter in the search path sequence. Just > having a decorating hook would not solve this issue. > Why is that? The searchpath isn't influenced at all, it is just that in one of the locations a specific verison is not there. What on the other hand could break is a superType chain, but This is something the developer should be aware when implementing. (given that decoration could be removal as well) > Regards > Felix > > — > Felix Meschberger | Principal Scientist | Adobe > > > > Am 14.11.2013 um 23:56 schrieb Mike Müller <[email protected]>: > > > To confirm what Dominik mentioned: > > The existing ResourceAccessGate would allow to grant or deny access > > to resources. IMHO there's no need to implement another interface or > > hook to achieve what is requested in the perspective of granting or > denying > > access to resources based on feature flag. Just implement a > > FeatureFlagResourceGate (or whatever name would make sense).. > > > > best regards > > Mike > > > >> -----Original Message----- > >> From: Dominik Süß [mailto:[email protected]] > >> Sent: Thursday, November 14, 2013 1:07 PM > >> To: dev > >> Subject: Re: FYI: feature flags prototype > >> > >> +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 <[email protected]> > 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 <[email protected] > > > >>> 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üß <[email protected]>: > >>>> > >>>>> 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 <[email protected]> > >> 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 < > >>>>>>> [email protected]> wrote: > >>>>>>> > >>>>>>> Hi Dominik, > >>>>>>>> > >>>>>>>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß < > >>> [email protected]> > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>> > >
