From: Felix Meschberger <fmesc...@adobe.com> > 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 :-) )
The problem of integrating that right into the resource resolver impl is that there is an unknown complexity in when those flags should be enabled or not. This might be whether this resource resolver is created from the request or not, certain user or other application conditions. Since it's a new idea, it isn't really clear yet. Thus it is IMO out of the question to add such unclear configurability to the resource resolver impl itself. Adding a dedicated service interface for that is better, as it at least decouples that from the impl and makes it possible to play around independently on the application level. However, the interface itself isn't clear yet - as mentioned, some things might depend on the context of how the resource resolver was created in the first place.... so it might be best to start playing around with the ResourceAccessGate (even if it is some more work atm) to see what the real needs are and to carve a new dedicated service interface etc. from there. > 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. I guess the feature flags need to do more... although it would be nice if you can reduce the use case to this and replace with a resource type that e.g. returns a 404 or does nothing (in case of an included resource). Cheers, Alex
