Thanks. This sounds like a reasonable idea. Justin
On Mar 8, 2010, at 9:32 AM, Carsten Ziegeler <[email protected]> wrote: > 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]
