You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2010/03/05 11:42:37 UTC
[RT] ResourceTypeProvider
Hi,
we discussed this topic a little bit from time to time and with the
recent changes of SLING-1420 it's obvious that the current approach, the
JcrResourceNodeTypeProvider which gets a node and maybe returns a
resource type, is not sufficient and has some problems.
Now one solution would be to have something like
interface ResourceTypeProvider {
String getResourceType(Resource)
}
This would be analog to the JcrResourceTypeProvider. However this kind
of looks wrong to me, as first a resource is created - with a resource
type amongst others - and then a new resource (or wrapper) needs to be
created with the new resource type.
So we could change this to something like
interface ResourceTypeProvider {
String getResourceType(String path, String resourceType,
ResourceMetadata metadata)
}
which doesn't look very appealing to me.
While thinking about this, the question came up if we could have the use
case where a provider not only wants to provide a different resource
type but maybe also a different resource super type?
What about additional metadata?
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....
Is this YAGNI?
WDYT?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Mar 8, 2010 at 4:57 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Vidar Ramdal wrote
>> On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler <cz...@apache.org> 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 <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Vidar Ramdal wrote
>
> ("Vidam" would probably vote for "decorade" :)
>
:) Seems to be my DOTT today (day of the typo)....
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Vidar Ramdal <vi...@idium.no>.
On Tue, Mar 9, 2010 at 10:06 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote
>> On Tue, Mar 9, 2010 at 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> Is everyone fine if we add the following interface to the API?
>>>
>>> interface ResourceDecorator {
>>> Resource decorade(Resource)
>>> Resource decorade(Resource, HttpServletRequest)
>>> }
>>
>> Why not SlingHttpServletRequest?
> We use HttpServletRequest in the resource resolver as well :)
>
>> +1 anyway if there's a good reason to use HttpServletRequest.
>>
>> (and typo: should be "decorate" of course)
+1 for introducing this interface
("Vidam" would probably vote for "decorade" :)
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote
> On Tue, Mar 9, 2010 at 10:07 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> On 09.03.2010 09:53, Bertrand Delacretaz wrote:
>> ...
>>>> interface ResourceDecorator {
>>>> Resource decorade(Resource)
>>>> Resource decorade(Resource, HttpServletRequest)
>>>> }
>>>
>>> Why not SlingHttpServletRequest?
>>
>> The resolve method is called with a HttpServletRequest because at the
>> time this method is called, the SlingHttpServletRequest does not exist
>> yet. [ The resolve method is called to create that object ]
>
> Ok for the resolve() method, but when decorate() is called I assume we
> do have an SlingHttpServletRequest at the point where decorate(...) is
> called, or not?
>
> (haven't checked exactly where Carsten plans to call decorate() )
>
No, we don't :) The Decorator is called from the resource resolver and
the result of the resource resolver is then used to create the sling
request object.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 9, 2010 at 10:07 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 09.03.2010 09:53, Bertrand Delacretaz wrote:
>...
>>> interface ResourceDecorator {
>>> Resource decorade(Resource)
>>> Resource decorade(Resource, HttpServletRequest)
>>> }
>>
>> Why not SlingHttpServletRequest?
>
> The resolve method is called with a HttpServletRequest because at the
> time this method is called, the SlingHttpServletRequest does not exist
> yet. [ The resolve method is called to create that object ]
Ok for the resolve() method, but when decorate() is called I assume we
do have an SlingHttpServletRequest at the point where decorate(...) is
called, or not?
(haven't checked exactly where Carsten plans to call decorate() )
-Bertrand
Re: [RT] ResourceTypeProvider
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 09.03.2010 09:53, Bertrand Delacretaz wrote:
> On Tue, Mar 9, 2010 at 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Is everyone fine if we add the following interface to the API?
>>
>> interface ResourceDecorator {
>> Resource decorade(Resource)
>> Resource decorade(Resource, HttpServletRequest)
>> }
>
> Why not SlingHttpServletRequest?
The resolve method is called with a HttpServletRequest because at the
time this method is called, the SlingHttpServletRequest does not exist
yet. [ The resolve method is called to create that object ]
Regards
Felix
>
> +1 anyway if there's a good reason to use HttpServletRequest.
>
> (and typo: should be "decorate" of course)
>
> -Bertrand
>
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote
> On Tue, Mar 9, 2010 at 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Is everyone fine if we add the following interface to the API?
>>
>> interface ResourceDecorator {
>> Resource decorade(Resource)
>> Resource decorade(Resource, HttpServletRequest)
>> }
>
> Why not SlingHttpServletRequest?
We use HttpServletRequest in the resource resolver as well :)
> +1 anyway if there's a good reason to use HttpServletRequest.
>
> (and typo: should be "decorate" of course)
LOL - good catch!
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 9, 2010 at 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Is everyone fine if we add the following interface to the API?
>
> interface ResourceDecorator {
> Resource decorade(Resource)
> Resource decorade(Resource, HttpServletRequest)
> }
Why not SlingHttpServletRequest?
+1 anyway if there's a good reason to use HttpServletRequest.
(and typo: should be "decorate" of course)
-Bertrand
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> On 09.03.2010 09:34, Carsten Ziegeler wrote:
>> Is everyone fine if we add the following interface to the API?
>>
>> interface ResourceDecorator {
>> Resource decorade(Resource)
>> Resource decorade(Resource, HttpServletRequest)
>> }
>>
>> This would be analogue to the ResourceResolver interface.
>
> +1
>
> One question: the decorator would be called for all methods returning
> Resource instances, right ? That is, besides getResource and resolve()
> it would also be called for the resources returned by findResource.
>
Yes, and also for the list children etc.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 09.03.2010 09:34, Carsten Ziegeler wrote:
> Is everyone fine if we add the following interface to the API?
>
> interface ResourceDecorator {
> Resource decorade(Resource)
> Resource decorade(Resource, HttpServletRequest)
> }
>
> This would be analogue to the ResourceResolver interface.
+1
One question: the decorator would be called for all methods returning
Resource instances, right ? That is, besides getResource and resolve()
it would also be called for the resources returned by findResource.
Regards
Felix
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Is everyone fine if we add the following interface to the API?
interface ResourceDecorator {
Resource decorade(Resource)
Resource decorade(Resource, HttpServletRequest)
}
This would be analogue to the ResourceResolver interface.
Carten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote
> Justin Edelson wrote:
>>> 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.
>>
> While the map approach would be the most flexible one, I think we don't
> need it atm - the problem with the map is that there has to be someone
> who fills the map before passing it to the decorator. This is the
> resource resolver and the resource resolver itself has no context object
> when resources are resolved. It might have the request object, therefore
> I think Vidam's proposal is fine.
Ups, sorry, I meant Vidar's proposal of course!
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Justin Edelson wrote:
>> 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.
>
While the map approach would be the most flexible one, I think we don't
need it atm - the problem with the map is that there has to be someone
who fills the map before passing it to the decorator. This is the
resource resolver and the resource resolver itself has no context object
when resources are resolved. It might have the request object, therefore
I think Vidam's proposal is fine.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Justin Edelson <ju...@gmail.com>.
On 3/8/10 10:57 AM, Carsten Ziegeler wrote:
> Vidar Ramdal wrote
>> On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler <cz...@apache.org> 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
>
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
Vidar Ramdal wrote
> On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler <cz...@apache.org> 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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Mar 8, 2010 at 3:32 PM, Carsten Ziegeler <cz...@apache.org> 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.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: [RT] ResourceTypeProvider
Posted by Justin Edelson <ju...@gmail.com>.
Thanks. This sounds like a reasonable idea.
Justin
On Mar 8, 2010, at 9:32 AM, Carsten Ziegeler <cz...@apache.org>
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
>> <fm...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> On 05.03.2010 15:08, Vidar Ramdal wrote:
>>>>>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <
>>> cziegeler@apache.org> 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 <js...@day.com>
>>>> 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
> cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> On 05.03.2010 15:08, Vidar Ramdal wrote:
>>>>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <
>> cziegeler@apache.org> 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 <js...@day.com> 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
cziegeler@apache.org
Re: [RT] ResourceTypeProvider
Posted by Justin Edelson <ju...@gmail.com>.
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?
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")?
Justin
On Mon, Mar 8, 2010 at 9:03 AM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> On 05.03.2010 15:08, Vidar Ramdal wrote:
> >>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <
> cziegeler@apache.org> 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 <js...@day.com> 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
> >
>
Re: [RT] ResourceTypeProvider
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 05.03.2010 15:08, Vidar Ramdal wrote:
>>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <cz...@apache.org> 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 <js...@day.com> 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
>
Re: [RT] ResourceTypeProvider
Posted by Vidar Ramdal <vi...@idium.no>.
>> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <cz...@apache.org> 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 <js...@day.com> 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.
The concept you guys come up with here looks really useful for this purpose.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: [RT] ResourceTypeProvider
Posted by Julian Sedding <js...@day.com>.
Hi
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);
}
Regards
Julian
On Fri, Mar 5, 2010 at 11:54 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <cz...@apache.org> 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....
>
> 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 ;-)
>
> -Bertrand
>
Re: [RT] ResourceTypeProvider
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Mar 5, 2010 at 11:42 AM, Carsten Ziegeler <cz...@apache.org> 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....
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 ;-)
-Bertrand