Re: Binding to a resource Type
The patch is re worked and refreshed at http://codereview.appspot.com/67146 but NonExistingResource needs to be non final (as does the getResourceType method) and reading the comments in that class, this might not be a good idea. Would it be better to use a synthetic ? Ian On 3 Jun 2009, at 16:46, Ian Boston wrote: Thanks, the points all make sense I will rework the patch. Ian On 3 Jun 2009, at 14:21, Felix Meschberger wrote: Hi Ian I have posted a review there. Regards Felix Ian Boston schrieb: I have pushed a patch for inspection at http://codereview.appspot.com/67146 Is this along the lines you were thinking ? Ian On 3 Jun 2009, at 10:14, Felix Meschberger wrote: It might be conceivable though to set the resourceSuperType of such non-existing resources to something configurable. To do this I would suggest to introduce a new service interface, which would be called when the ResourceResolver is about to create the NonExistingResource
Re: Binding to a resource Type
Thanks, the points all make sense I will rework the patch. Ian On 3 Jun 2009, at 14:21, Felix Meschberger wrote: Hi Ian I have posted a review there. Regards Felix Ian Boston schrieb: I have pushed a patch for inspection at http://codereview.appspot.com/67146 Is this along the lines you were thinking ? Ian On 3 Jun 2009, at 10:14, Felix Meschberger wrote: It might be conceivable though to set the resourceSuperType of such non-existing resources to something configurable. To do this I would suggest to introduce a new service interface, which would be called when the ResourceResolver is about to create the NonExistingResource
Re: Binding to a resource Type
Hi Ian I have posted a review there. Regards Felix Ian Boston schrieb: > I have pushed a patch for inspection at > http://codereview.appspot.com/67146 > > Is this along the lines you were thinking ? > Ian > > On 3 Jun 2009, at 10:14, Felix Meschberger wrote: > >> It might be conceivable though to set the resourceSuperType of such >> non-existing resources to something configurable. To do this I would >> suggest to introduce a new service interface, which would be called when >> the ResourceResolver is about to create the NonExistingResource > >
Re: Binding to a resource Type
I have pushed a patch for inspection at http://codereview.appspot.com/67146 Is this along the lines you were thinking ? Ian On 3 Jun 2009, at 10:14, Felix Meschberger wrote: It might be conceivable though to set the resourceSuperType of such non-existing resources to something configurable. To do this I would suggest to introduce a new service interface, which would be called when the ResourceResolver is about to create the NonExistingResource
Re: Binding to a resource Type
On 3 Jun 2009, at 10:14, Felix Meschberger wrote:
Hi,
Each ResourceProvider is responsible for setting up resources
themselves, including setting the resource type. For example the
BundleResourceProvider sets the resource type to nt:file or nt:folder
depending on whether the resource is a file or folder.
The JcrResourceProvider now uses the ResourceTypeProvider service to
enhance its resource type resolution:
(1) check sling:resourceType property
(2) check ResourceTypeProvider services
(3) take primary node type
Ok, that makes sense, clearly changing ResourceTypeProvider would be
the wrong thing to do
thank you.
Your (remaining) problem probably is the resource type of non-existing
resources which is currently hard coded to sling:nonexisting and it is
also defined in the API that a non existing resource has the
sling:nonexisting resource type.
It might be conceivable though to set the resourceSuperType of such
non-existing resources to something configurable. To do this I would
suggest to introduce a new service interface, which would be called
when
the ResourceResolver is about to create the NonExistingResource.
Ok, I will give that a go, sounds like a far better than a
ResourceProvider place to put this stuff.
Thanks
Ian
Regards
Felix
Ian Boston schrieb:
On 3 Jun 2009, at 09:26, Felix Meschberger wrote:
Not in the sense of "inheriting the resource type from the parent
node
if none is set".
But: We have a ResourceTypeProvider service interface, which you may
implement. This provider is called by the JcrResourceProvider if a
node
has no sling:resourceType property.
In a custom resource provider, you could find a sling:resourceType
property up the ancestors of the node to build inheritance this way.
HTH
Felix,
Yes It does to a degree
I had a look at that interface and it works if there is a Node, but
URL
does not directly map to the JCR path either because the JCR path
doesnt
exist yet, or because there is mapping between the URL and the JCR
path,
then there is no Node, so the JcrResourceType doesnt get called.
What *would* work is something like
/**
* Provide a resource type for resource paths which do not have
* resourceType.
*/
public interface ResourceTypeProvider {
/**
* Return the resource type to use for the node.
* @param absPath The node.
* @return The resource type to use or null.
*/
String getResourceTypeForPath(String absPath) throws
RepositoryException;
}
That would also get rid of the need for my patch local on
ResourceProvider registrations (classifier)
Ian
Regards
Felix
Re: Binding to a resource Type
Hi,
Each ResourceProvider is responsible for setting up resources
themselves, including setting the resource type. For example the
BundleResourceProvider sets the resource type to nt:file or nt:folder
depending on whether the resource is a file or folder.
The JcrResourceProvider now uses the ResourceTypeProvider service to
enhance its resource type resolution:
(1) check sling:resourceType property
(2) check ResourceTypeProvider services
(3) take primary node type
Your (remaining) problem probably is the resource type of non-existing
resources which is currently hard coded to sling:nonexisting and it is
also defined in the API that a non existing resource has the
sling:nonexisting resource type.
It might be conceivable though to set the resourceSuperType of such
non-existing resources to something configurable. To do this I would
suggest to introduce a new service interface, which would be called when
the ResourceResolver is about to create the NonExistingResource.
Regards
Felix
Ian Boston schrieb:
>
> On 3 Jun 2009, at 09:26, Felix Meschberger wrote:
>
>> Not in the sense of "inheriting the resource type from the parent node
>> if none is set".
>>
>> But: We have a ResourceTypeProvider service interface, which you may
>> implement. This provider is called by the JcrResourceProvider if a node
>> has no sling:resourceType property.
>>
>> In a custom resource provider, you could find a sling:resourceType
>> property up the ancestors of the node to build inheritance this way.
>>
>> HTH
>
> Felix,
>
> Yes It does to a degree
>
> I had a look at that interface and it works if there is a Node, but URL
> does not directly map to the JCR path either because the JCR path doesnt
> exist yet, or because there is mapping between the URL and the JCR path,
> then there is no Node, so the JcrResourceType doesnt get called.
>
> What *would* work is something like
>
> /**
> * Provide a resource type for resource paths which do not have
> * resourceType.
> */
> public interface ResourceTypeProvider {
>
> /**
> * Return the resource type to use for the node.
> * @param absPath The node.
> * @return The resource type to use or null.
> */
> String getResourceTypeForPath(String absPath) throws
> RepositoryException;
> }
>
> That would also get rid of the need for my patch local on
> ResourceProvider registrations (classifier)
>
> Ian
>
>
>>
>>
>> Regards
>> Felix
>
>
Re: Binding to a resource Type
On 3 Jun 2009, at 09:26, Felix Meschberger wrote:
Not in the sense of "inheriting the resource type from the parent node
if none is set".
But: We have a ResourceTypeProvider service interface, which you may
implement. This provider is called by the JcrResourceProvider if a
node
has no sling:resourceType property.
In a custom resource provider, you could find a sling:resourceType
property up the ancestors of the node to build inheritance this way.
HTH
Felix,
Yes It does to a degree
I had a look at that interface and it works if there is a Node, but
URL does not directly map to the JCR path either because the JCR path
doesnt exist yet, or because there is mapping between the URL and the
JCR path, then there is no Node, so the JcrResourceType doesnt get
called.
What *would* work is something like
/**
* Provide a resource type for resource paths which do not have
* resourceType.
*/
public interface ResourceTypeProvider {
/**
* Return the resource type to use for the node.
* @param absPath The node.
* @return The resource type to use or null.
*/
String getResourceTypeForPath(String absPath) throws
RepositoryException;
}
That would also get rid of the need for my patch local on
ResourceProvider registrations (classifier)
Ian
Regards
Felix
Re: Binding to a resource Type
Hi, Ian Boston schrieb: > > On 3 Jun 2009, at 06:32, Felix Meschberger wrote: > >> Hi Ian, >> >> Ian Boston schrieb: >>> Should a servlet (with sling.servlet.resourceTypes value="x") bind to >>> JCR nodes where a parent node has a resourceType of x, or will it only >>> bind to JCR nodes where the node itself has the resourceType x ? >> >> I do not exactly understand what you mean by "bind to JCR nodes" ? >> > > > I mean, when I have servlet with >> sling.servlet.resourceTypes = "x" > > and send a request for node with a sling:resourceType=x the request will > get routed to the servlet (assuming it can handle the request method, > and selector) > > However, > If I send a request for a child node of the node with > sling:resourceType=x, the request does not get routed to the servlet. Correct. Each resource has its own resource type. > ie there is no resourceType inheritance by default in Sling. Not in the sense of "inheriting the resource type from the parent node if none is set". But: We have a ResourceTypeProvider service interface, which you may implement. This provider is called by the JcrResourceProvider if a node has no sling:resourceType property. In a custom resource provider, you could find a sling:resourceType property up the ancestors of the node to build inheritance this way. HTH Regards Felix > > Ian > > >> Registered servlets are not "bound to JCR nodes" but are added to the >> resource tree at predefined locations. For example a servlet >> registered with >> >> sling.servlet.resourceTypes = "x" >> sling.servlet.extensions = "html" >> >> is added to the resource tree (by default) at >> >> /apps/x/html.servlet >> >> This node (a leaf actually) in the resource tree is not backed by a JCR >> item and is only accessible through the resource resolver and only >> exists as long as the Servlet Resolver is active and the servlet is >> registered. >> >> Hope this helps. >> >> Regards >> Felix > >
Re: Binding to a resource Type
On 3 Jun 2009, at 06:32, Felix Meschberger wrote: Hi Ian, Ian Boston schrieb: Should a servlet (with sling.servlet.resourceTypes value="x") bind to JCR nodes where a parent node has a resourceType of x, or will it only bind to JCR nodes where the node itself has the resourceType x ? I do not exactly understand what you mean by "bind to JCR nodes" ? I mean, when I have servlet with sling.servlet.resourceTypes = "x" and send a request for node with a sling:resourceType=x the request will get routed to the servlet (assuming it can handle the request method, and selector) However, If I send a request for a child node of the node with sling:resourceType=x, the request does not get routed to the servlet. ie there is no resourceType inheritance by default in Sling. Ian Registered servlets are not "bound to JCR nodes" but are added to the resource tree at predefined locations. For example a servlet registered with sling.servlet.resourceTypes = "x" sling.servlet.extensions = "html" is added to the resource tree (by default) at /apps/x/html.servlet This node (a leaf actually) in the resource tree is not backed by a JCR item and is only accessible through the resource resolver and only exists as long as the Servlet Resolver is active and the servlet is registered. Hope this helps. Regards Felix
Re: Binding to a resource Type
Hi Ian, Ian Boston schrieb: > Should a servlet (with sling.servlet.resourceTypes value="x") bind to > JCR nodes where a parent node has a resourceType of x, or will it only > bind to JCR nodes where the node itself has the resourceType x ? I do not exactly understand what you mean by "bind to JCR nodes" ? Registered servlets are not "bound to JCR nodes" but are added to the resource tree at predefined locations. For example a servlet registered with sling.servlet.resourceTypes = "x" sling.servlet.extensions = "html" is added to the resource tree (by default) at /apps/x/html.servlet This node (a leaf actually) in the resource tree is not backed by a JCR item and is only accessible through the resource resolver and only exists as long as the Servlet Resolver is active and the servlet is registered. Hope this helps. Regards Felix
