Justin Edelson wrote > Hi all, > I'm afraid I'm missing something here. With this new interface, who is > responsible for setting the resource type and super type? Like before, it's the task of the resource resolver factory. However, after the resource is created with resource type, super type, metadata etc. all ResourceDecorators are queried (ordered by service ranking). They get the current resource and either return it directly (if they don't want to decorate it) or create a new resource - which usually is just a decoration - but it could also be a completly different resource with different behaviour.
> > On a (slightly) separate topic - I'm curious how people thing these > decorator services should be registered, i.e. how does a ResourceDecorator > express which types of resources it wants to decorate? Things that come to > mind are: > * resource provider > * path prefix > * resource type > * resource super type > > Any others (something like "adapatable to")? Yes, I thought about this as well - as a first implementation we simply pass all resources through all registered decorators - so it is up to the decorator to make the decision. Performance wise this shouldn't make a difference. Carsten > > Justin > > On Mon, Mar 8, 2010 at 9:03 AM, Felix Meschberger <[email protected]>wrote: > >> Hi, >> >> On 05.03.2010 15:08, Vidar Ramdal wrote: >>>>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler < >> [email protected]> wrote: >>>>>> ...We could make a general approach like (I couldn't make up could >> names >>>>>> for the interface and methods...) >>>>>> >>>>>> interface ResourceProcessor { >>>>>> >>>>>> Resource process(Resource); >>>>>> } >>>>>> >>>>>> so basically this works like kind of a filter which is able to >>>>>> substitute a resource with a completly different one - this could be >>>>>> used to change the resource type, the super resource type, metadata, >>>>>> different implementations of the adaptTo method etc. Everything is >>>>>> possible.... >>> >>>> On Fri, Mar 5, 2010 at 11:54 AM, Bertrand Delacretaz >>>>> I like the idea, we could call it ResourceFilter maybe? As you >>>>> indicate it's filtering the resource after it's loaded. >>>>> >>>>> It's a sharp knife though, could probably be abused in several ways - >>>>> but as all Sling components are replaceable anyway, it doesn't make >>>>> much of a difference. >>>>> >>>>> I'd say go for it, but watch out for which implementations we create >> ;-) >>> >>> On Fri, Mar 5, 2010 at 2:10 PM, Julian Sedding <[email protected]> wrote: >>>> I like the idea and implementing this in a generic fashion seems >> sensible to me. >>>> >>>> Regarding the naming, what about: >>>> >>>> interface ResourceDecoratorFilter { >>>> Resource decorate(Resource); >>>> } >>> >>> I really like this idea, I have been thinking about something similar: >>> A ResourceDecorator which would provide dynamic property values, like >>> a count of its child resources, or a sum of products in a shopping >>> basket. >> >> I like the ResourceDecorator, too. >> >>> >>> The concept you guys come up with here looks really useful for this >> purpose. >> >> +1 >> >> Regards >> Felix >>> >> > -- Carsten Ziegeler [email protected]
