On 3/8/10 10:57 AM, Carsten Ziegeler 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.
How about:
interface ResourceDecoratorFilter {
Resource decorate(Resource resource, Map<String,Object> context);
}
Having access to the request object is important IMHO.
Justin
>
> Carsten
>
