Yes, now it pays back that we had strong oponents of simply calling the ResourceAccessGate for every provider... :( But we can reconsider this and are done.
For alternate rendering we can use a resource decorator - instead of using different scripts for the same resource type, the decorator returns a resource which has a different resource type. This would require zero changes to the script handling. Carsten 2013/12/10 Felix Meschberger <fmesc...@adobe.com> > Hi > > Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz <bdelacre...@apache.org > >: > > > On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: > >> ...I think it has been mentioned as well, ResourceAccessGate does > exactly what > >> is needed for handling frags on resources - it filters and allows to > return > >> null (deny access) based on some implementation. So why aren't we using > >> this?... > > > > IIRC the comments were that ResourceAccessGate has to be wired for > > each ResourceProvider - if there's a way to define "global" > > ResourceAccessGates that might work. > > Right ResourceAccessGate was invented to support ResourceProvider services > which do not do access control themselves. So it is an access control > feature. > > I would like to keep feature flags separate from access control. Its a > different domain with mostly different administrators: I don't think we > should require user/acl karma to enable/disable feature flags. > > Regards > Felix > > > > > I have added a few basic use cases at > > > https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support > , > > I guess we're mostly looking at "show/hide Resources" here which might > > cover "alter resource rendering" as well, but caching of rendering > > scripts is an issue. > > > > -Bertrand > > -- Carsten Ziegeler cziege...@apache.org
