On Mon, Mar 8, 2010 at 4:57 PM, Carsten Ziegeler <[email protected]> wrote: > Vidar Ramdal wrote >> On Mon, Mar 8, 2010 at 3:32 PM, 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. >> >> What information will be made available to ResourceDecorators? >> I can easily see cases where you'd want a given resource decorated >> only in certain circumstances, like when a specific request query >> parameter is present. >> > Hmm, ok, good question. So far, we only pass in the Resource - so the > decorator can access all resource related information - of course this > would not include a query parameter or something like that. > > I'm not sure if we should pass in more parameters like the request etc. > We could do this however these additional things would be optional as > the resource resolver may be used out of the scope of a request.
Yeah, that approach makes sense for ResourceResolver, with ResourceResolver.resolve(String) vs ResourceResolver.resolve(HttpServletRequest, String). Maybe that would be good for ResourceDecorator too. -- Vidar S. Ramdal <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
