Hi Bertrand,
2013/12/31 Bertrand Delacretaz <bdelacre...@apache.org>
>
> So IIUC the when hiding a resource or changing its resource type the
> scenario is as follows?
>
> 1. ResourceResolver checks all existing features to see which ones are
> active in the given context.
>
>
This is done outside of the resource resolver once per request - once the
resource
resolver is invoked, the feature flags implementation knows already which
features are
active.
> 2. For each active feature, ResourceResolver calls
> FeatureProvider.hideResource and
> FeatureProvider.getResourceTypeMapping to find out if resource
> manipulations are needed.
>
>
It's not done by the resource resolver, but basically yes.
> If I'm correct, that's a bit expensive for our 10'000 features (yes I
> bet creative users will get there ;-)
>
> Well, I personally doubt that this is realistic and will create all kinds
of problems if used in such an extensive number, but I guess it's pointless
to argue about a fictional number anyway :) So, I agree we should prepare
for the worse...
> How about making a Feature an object, instead of just a String:
>
> Feature {
> String getName();
> String getDescription();
> boolean hasResourceTypeMapping();
> boolean canHideResource();
> }
>
> The ResourceResolver can then consider only the features which are
> marked for resource type mapping or for hiding resources. And having a
> feature description can be useful for troubleshooting, webconsole etc.
>
>
Yes, I was thinking about this as well - especially as we might have new
functionality to be influenced by features in the future (like service
lookup etc.), so I thought about making this more generic and have an
adaptTo method on the Feature class instead and each functionality
(resource type mapping, hiding resources) gets an own interface and either
the feature can be adapted to this or now. So calling adaptTo would be the
equivalent of hasXXX or canXXX.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
