I have another use case for the decorator, it's possible to "enhance" resources with data coming from a different location, so for example for the file resource provider I could store metadata about a file somewhere else and combine the information. This would also support updating/creating the metadata. This is also implementable by implementing a new resource provider which combines the input of two other resource providers, but a decorator would make this nicer/easier.
Carsten 2013/3/7 Carsten Ziegeler <[email protected]>: > Hi, > > as recent discussion showed, there might be use cases for a resource > provider decorator. A decorator can be used to add functionality > across several resource providers. E.g. this would simplify securing > resource providers which don't support access checks ootb, like the > file resource provider or the MongoDB resource provider. > > Decorating a resource provider is not as trivial as decorating a > resource because a provider might come in different flavours = > implement additional functionality through sub interfaces. > So I think just having a single decorate method is too error-prone as > the implementation would have to check whether a resource provider > implements those interfaces and construct a corresponding resource > provider. > > Therefore I propose we add a simple interface: > public interface ResourceProviderDecorator { > > ResourceProvider decorate(final ResourceProvider provider); > > AttributableResourceProvider decorate(final > AttributableResourceProvider provider); > > ModifyingResourceProvider decorate(final ModifyingResourceProvider > provider); > > QueriableResourceProvider decorate(final QueriableResourceProvider > provider); > > DynamicResourceProvider decorate(final DynamicResourceProvider provider); > } > > which allows to decorate each separately. At the same time we add > wrapper implementations for all of the above which delegate to the > passed in resource provider. This makes the implementation much > easier. > > The decorators are ordered by their service ranking and called in this order. > > WDYT? > > Regards > Carsten > -- > Carsten Ziegeler > [email protected] -- Carsten Ziegeler [email protected]
