Hi Ruben, the intention is to disable features that are not should not be globally available but might be activated under certain conditions. This reduces the need to branch non-production ready features away and merge them in later and opens the option to have something like a "Friendly user Test" or softlaunch of a feature. Therefore this can be something big or something small. I think a solution should be capable of dealing with both. The java API would allow to hook in at any granularity level of the application so this already fullfills the requirements I'd have. Adding a corresponding declarative logic to filter the resourcetree would give the same coarse and/or finegrained filtermechanism to the resolutionprocess.
What still would be missing is controlling updates and not just additions. e.g. when a resource should be rendered by a new version of a resourceType - in such case it might be an option to extend the searchpath from /libs/../myresourcetype, /apps/../myresourcetype by featurespecific overlaypaths that would either be searched when a feature is activated or hidden if the feature is deactivated. This would require refactoring later on but would allow parallel existance of multiple versions of a resourceType. Best regards, Dominik On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser <r...@headwire.com> wrote: > Bertrand, Dominik, > > the feature flag may also have an impact on the nodes/properties that you > need to render the feature. Being able to handle this in the resource tree > directly without having to handle it in component code would be great. > However, I am not sure if the intention of the feature flag was more to > enable/change little features (code fragment) and not really change big > things (leave that to test&target or other products?) > > Ruben > > > On 11/13/2013 6:32 AM, Dominik Süß wrote: > >> Hi Bertrand, >> >> the UI of an application based on Sling are often composed of existing >> resourceTypes so you cannot just decide in the code to display or not to >> display so you have to "annotate"/"flag" the resources and then have some >> code deciding if this resource should be rendered or not. For sure you >> could add code to each resource to check if it is to be rendered but this >> is a lot of repetive code. Another option would be a Servlet filter to >> skip >> inclusion at that Point. But this all fails in some situations like >> whenyou >> consume an aggregated json dump and use this on client side. Therefore the >> only shared location that all code should act on when looking at the >> persistance is the resourcetree, and as already existing API the Access >> Gate API seems to be capable of doing exactly what is required - masking >> the resourcetree based on custom logic. >> >> Best regards >> Dominik >> >> >> On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz < >> bdelacre...@apache.org> wrote: >> >> Hi Dominik, >>> >>> On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß <dominik.su...@gmail.com> >>> wrote: >>> >>>> ...as far as I can see the API is just covering the java aspect of >>>> >>> this... >>> >>> Nothing prevents you from using the FeatureFlags service in scripted >>> code. >>> >>> ....you could have a gate looking for a marker at a resource >>>> which indicates it to be part of a specific feature and therefore >>>> >>> disables >>> >>>> access to it.... >>>> >>> Do we need any changes to Sling or to this new API to enable that? >>> >>> The problem IMO is that this makes the whole thing less transparent >>> than using feature flags in the rendering code. OTOH if people can >>> implement it themselves (and add the corresponding info to >>> RequestProgressTracker) for transparency, I don't mind. >>> >>> -Bertrand >>> >>> >
