I think we're pretty clear now how we could implement this, basically
everything is in place, so the resource resolver has all features we need
in the way we need them. And we should now start defining the feature flags
api.

Carsten


2013/12/12 Alexander Klimetschek <aklim...@adobe.com>

> 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




-- 
Carsten Ziegeler
cziege...@apache.org

Reply via email to