:) Ok, but the resource access stuff is deep in the resource resolver already and provides the exact functionality we need: hiding a resource under some conditions - so why adding a second implementation, doubling the complexity in this area just with the same functionality? Of course the service which defines whether a resource is visible or not should look much different and directly suited to the featureflags requirements - but implementation wise we can simple use the resource access gate stuff and provide an implementation in the core which triggers the FeatureFlag stuff
Carsten 2013/12/11 Felix Meschberger <fmesc...@adobe.com> > Hi > > I disagree ;-) > > For "hiding" resources I would really prefer hooking into the > ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem > to repeat myself here, but I seem to have a strong position on that :-) ) > > As for changing the rendering, I would assume you primarily mean changing > the resource type (or may be the resource super type), I agree > ResourceDecorator is the way to go. > > Regards > Felix > > Am 11.12.2013 um 01:00 schrieb Carsten Ziegeler <cziege...@apache.org>: > > > So can we agree to continue with these two appraches: > > - global ResourceAccessSecurity for hidding resources > > - Decorator for changing rendering > > > > ? > > > > Carsten > > > > > > 2013/12/11 Bertrand Delacretaz <bdelacre...@apache.org> > > > >> On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler <cziege...@apache.org > > > >> wrote: > >>> ...it pays back that we had strong oponents of simply calling the > >>> ResourceAccessGate for every provider... > >> > >> If needed we could differentiate between global and per-provider > >> ResourceAccessGates using service properties. > >> > >> -Bertrand > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
