You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/11/01 12:22:28 UTC

Sling API: Hanlding non-existing resources in ResourceResolver

Hi all,

Currently the ResourceResolver.resolve(ServletRequest request) method
throws a ResourceNotFoundException if the request cannot be resolved to
a resource. This makes it virtually impossible to easily and
transparently handle requests for resource creation.

This in fact is also an overseen difference between microsling and
Sling: microsling is built around accepting missing resources while
Sling throws 404 unconditionally if a request cannot be resolved to a
resource. This prevents applications trying to create resources.

As a fix I propose the introduction of a new special resource type
"sling:nonexisting", which is to be used by the ResourceResolver.resolve
method to create a pseudo-Resource from the request path (rawData and
object are both null). This may then be used to create the resource,
such as in the DefaultSlingServlet. (The nice thing about the
sling:nonexisting resource type is, that of course scripts may be
created to handle respective methods for these types).

Consquences in the API: The methods of the ResourceResolver and
ResourceManager interfaces throwing a ResourceNotFoundException are
modified to return null if a Resource cannot be found (except the
resolve method which always returns a Resource instance, with the
sling:nonexisting resource type in the case of nonexisting resources).
And of course the ResourceNodeFoundException is dropped as it is not
needed any more.

I will modify the API to reflect this proposal.

WDYT ?

Regards
Felix


Re: Sling API: Hanlding non-existing resources in ResourceResolver

Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Sounds good to me, I never like throwing an exception if something  
cannot be found, as that seems to be a normal state when looking  
things up.

-paddy


On Nov 1, 2007, at 5:53 AM, Carsten Ziegeler wrote:

> Felix Meschberger wrote:
>> Hi all,
>>
>> Currently the ResourceResolver.resolve(ServletRequest request) method
>> throws a ResourceNotFoundException if the request cannot be  
>> resolved to
>> a resource. This makes it virtually impossible to easily and
>> transparently handle requests for resource creation.
>>
>> This in fact is also an overseen difference between microsling and
>> Sling: microsling is built around accepting missing resources while
>> Sling throws 404 unconditionally if a request cannot be resolved to a
>> resource. This prevents applications trying to create resources.
>>
>> As a fix I propose the introduction of a new special resource type
>> "sling:nonexisting", which is to be used by the  
>> ResourceResolver.resolve
>> method to create a pseudo-Resource from the request path (rawData and
>> object are both null). This may then be used to create the resource,
>> such as in the DefaultSlingServlet. (The nice thing about the
>> sling:nonexisting resource type is, that of course scripts may be
>> created to handle respective methods for these types).
>>
>> Consquences in the API: The methods of the ResourceResolver and
>> ResourceManager interfaces throwing a ResourceNotFoundException are
>> modified to return null if a Resource cannot be found (except the
>> resolve method which always returns a Resource instance, with the
>> sling:nonexisting resource type in the case of nonexisting  
>> resources).
>> And of course the ResourceNodeFoundException is dropped as it is not
>> needed any more.
>>
>> I will modify the API to reflect this proposal.
>>
>> WDYT ?
>>
> +1 :)
>
> Carsten
>
> -- 
> Carsten Ziegeler
> cziegeler@apache.org



Re: Sling API: Hanlding non-existing resources in ResourceResolver

Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi all,
> 
> Currently the ResourceResolver.resolve(ServletRequest request) method
> throws a ResourceNotFoundException if the request cannot be resolved to
> a resource. This makes it virtually impossible to easily and
> transparently handle requests for resource creation.
> 
> This in fact is also an overseen difference between microsling and
> Sling: microsling is built around accepting missing resources while
> Sling throws 404 unconditionally if a request cannot be resolved to a
> resource. This prevents applications trying to create resources.
> 
> As a fix I propose the introduction of a new special resource type
> "sling:nonexisting", which is to be used by the ResourceResolver.resolve
> method to create a pseudo-Resource from the request path (rawData and
> object are both null). This may then be used to create the resource,
> such as in the DefaultSlingServlet. (The nice thing about the
> sling:nonexisting resource type is, that of course scripts may be
> created to handle respective methods for these types).
> 
> Consquences in the API: The methods of the ResourceResolver and
> ResourceManager interfaces throwing a ResourceNotFoundException are
> modified to return null if a Resource cannot be found (except the
> resolve method which always returns a Resource instance, with the
> sling:nonexisting resource type in the case of nonexisting resources).
> And of course the ResourceNodeFoundException is dropped as it is not
> needed any more.
> 
> I will modify the API to reflect this proposal.
> 
> WDYT ?
> 
+1 :)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Sling API: Hanlding non-existing resources in ResourceResolver

Posted by Bertrand Delacretaz <bd...@apache.org>.
On 11/1/07, Felix Meschberger <fm...@gmail.com> wrote:

> ...As a fix I propose the introduction of a new special resource type
> "sling:nonexisting", which is to be used by the ResourceResolver.resolve
> method to create a pseudo-Resource from the request path (rawData and
> object are both null)....

Ok, and I'd make this pseudo resource an API class.

Having a NonExistingResource class with resourceType=sling:nonexisting
might make things clearer, and exposing this class in the API makes
the mechanism more obvious.

> ...I will modify the API to reflect this proposal...

+1

-Bertrand