Re: help, my content model looks un-Slingable
On Feb 20, 2008 4:37 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...The implementation of this path generation can be done in a new ResourceResolver.getSearchPath(Resource) method, which returns a dynamic search path including these sling:config resources if existing. This search path is then used by the servlet resolver to search for the scripts and may be used by others +1, this is similar to what microsling did. -Bertrand
Re: help, my content model looks un-Slingable
On 2/15/08, Jukka Zitting [EMAIL PROTECTED] wrote: How about allowing a sling:config child node that could be added to any node and could contain script and servlet mappings and other configuration settings that would apply only to that subtree? This would solve both this and the multiple domain issue from the other thread. That would be a great feature, and it could also be a large part of the solution for SLING-249. -- Vidar S. Ramdal [EMAIL PROTECTED] - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: help, my content model looks un-Slingable
Hi, On Feb 16, 2008 2:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 15.02.2008, 18:36 +0200 schrieb Jukka Zitting: How about allowing a sling:config child node that could be added to any node and could contain script and servlet mappings and other configuration settings that would apply only to that subtree? This would solve both this and the multiple domain issue from the other thread. This is definitely a better proposal than just depend on more or less accidental location of the resource. But if such a sling:config setup would influence any node below that node with the sling:config, this might have a dramatic influence on performance because on each request, we have to go up the tree looking for such a node... (ok, we could cache, but then we would have to manage that cache...) The repository implementation should generally already do a pretty good job of caching the parent nodes, and you in any case need to walk down the tree when mapping the URL to a resource. I'd collect any such configuration information as a part of the URL mapping process, where the overhead should be minimal. BR, Jukka Zitting
Re: help, my content model looks un-Slingable
Hi, Am Samstag, den 16.02.2008, 14:26 +0200 schrieb Jukka Zitting: Hi, On Feb 16, 2008 2:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 15.02.2008, 18:36 +0200 schrieb Jukka Zitting: How about allowing a sling:config child node that could be added to any node and could contain script and servlet mappings and other configuration settings that would apply only to that subtree? This would solve both this and the multiple domain issue from the other thread. This is definitely a better proposal than just depend on more or less accidental location of the resource. But if such a sling:config setup would influence any node below that node with the sling:config, this might have a dramatic influence on performance because on each request, we have to go up the tree looking for such a node... (ok, we could cache, but then we would have to manage that cache...) The repository implementation should generally already do a pretty good job of caching the parent nodes, and you in any case need to walk down the tree when mapping the URL to a resource. I'd collect any such configuration information as a part of the URL mapping process, where the overhead should be minimal. We don't walk down the tree. We currently do Session.hasItem(String) and Session.getItem(String) to find the matching item in the repository. We could of course definitely just give it a try. But what information would you store in the sling:config node ? mappings of resource type sets to replacement resource types ? Regards Felix
Re: help, my content model looks un-Slingable
Hi David, Am Samstag, den 16.02.2008, 09:43 +0100 schrieb David Nuescheler: Hi Jukka, I think that's a great idea. On top of that we used in microjax in case a node was not mapped we tried the following. if the node was located in /content/xyz we tried /apps/xyz as the default resource type which works out beatifully to keep simple applications simple. To address Michaels issue I would recommend to do the following: If a resource cannot be resolved to a resourcetype I would recommend to just go up the tree and take the resource type of the parent. I think that would easily address the issue of people that have a large tree of information but can't change anything in the tree itself. They can just apply a sling:resoureType to the root node of that tree and be done with it. A resource always has a resource type: either the sling:resourceType property or the primary node type. So there is no need to go up the tree in this case. Regards Felix regards, david On 2/15/08, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Fri, Feb 15, 2008 at 5:19 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Freitag, den 15.02.2008, 15:47 +0100 schrieb Michael Marth: Maybe it would be helpful if we had some additional script resolution based on URLs or paths. In my example I could map a script to nt:resource if the resource is below /content/mails or so. Such a mechanism could really be helpful for users that have no possibility to modify existing content. We have discussed and abandoned this idea before, because we could not find a generic and easy way of defining which part of the path would influence script selection. If you can provide us with such a definition, we would re-evaluate our findings. How about allowing a sling:config child node that could be added to any node and could contain script and servlet mappings and other configuration settings that would apply only to that subtree? This would solve both this and the multiple domain issue from the other thread. I suggested this already earlier, but the general response was that the mapping configuration should be a property of the components instead of the content. That's a valid point, but I think relaxing that criteria is the only way to allow this kind of customization. BR, Jukka Zitting
Re: help, my content model looks un-Slingable
Hi, Am Samstag, den 16.02.2008, 14:48 +0200 schrieb Jukka Zitting: Hi, On Feb 16, 2008 2:32 PM, Felix Meschberger [EMAIL PROTECTED] wrote: We don't walk down the tree. We currently do Session.hasItem(String) and Session.getItem(String) to find the matching item in the repository. The repository implementation (at least Jackrabbit) walks down the path, loading each node along the way when you do hasItem or getItem, so the performance difference to doing it explicitly in client code should be minimal (there's just some in-memory overhead). We could of course definitely just give it a try. But what information would you store in the sling:config node ? mappings of resource type sets to replacement resource types ? Replacement types might be OK, but I'd store direct resource type - component mappings. This way you could for example deploy multiple components designed for nt:file, and configure per subtree which one of those components should be effective. This is what I propose. Consider the following structure: /parent +-- /sling:config nt:file = some:resource +-- /child jcr:primaryType = nt:file When requesting /parent/child the resource type is first set to nt:file. the the sling:config node of /parent is looked up for a mapping for nt:file thus overwriting the resource tpye of /parent/child to be some:resource Even more interesting would be to allow you to put scripts directly under the sling:config node. This way I could easily experiment with new scripts on just a small part of my site. Hmm to be further investigated Regards Felix
Re: help, my content model looks un-Slingable
Hi Felix, thanks a lot - I'll give it a try. Maybe it would be helpful if we had some additional script resolution based on URLs or paths. In my example I could map a script to nt:resource if the resource is below /content/mails or so. Such a mechanism could really be helpful for users that have no possibility to modify existing content. Cheers Michael On 2/15/08, Felix Meschberger [EMAIL PROTECTED] wrote: Hi Michael, I just updated the jcr/resource module to create a sling:Resource mixin node type, which defines a sling:resourceType property as a String. You may attach this mixin node type to your mail node and set resource type accordingly. This gives you the full flexibility to render your mail specifically. Alternatively, of course, you may create a servlet or script for the nt:file resource type. But this has the advantage that all nt:file nodes regardless of whether they are actually mail or not will be rendered by that servlet or script. The first option is probably better. Regards Felix Am Freitag, den 15.02.2008, 11:52 +0100 schrieb Michael Marth: Hi, I have an existing content model and want to build a sling app on top. The model is Jukka Zitting's mail model he coded for James (see [1]). One mail is stored as: nt:file |-jcr:content (unstructured) |- from (string) |- to (string) |- jcr:data (binary) ... In order to display a mail via Sling I added a property sling:resourceType to the jcr:content sub node (because I could not add it to nt:file). My URL now looks something like: http://localhost:/content/.../emailtitle/jcr:content or http://localhost:/content/.../emailtitle but in both cases the binary jcr:data is returned directly. Do I have to change my content model or do you guys see a way that I can access my mail resources and have a script being executed? Thanks for hints Cheers Michael [1] http://dev.day.com/microsling/content/blogs/main/jcrmail.html -- Michael Marth, http://dev.day.com
Re: help, my content model looks un-Slingable
Hi Michael, Am Freitag, den 15.02.2008, 15:47 +0100 schrieb Michael Marth: Hi Felix, thanks a lot - I'll give it a try. Cool. Maybe it would be helpful if we had some additional script resolution based on URLs or paths. In my example I could map a script to nt:resource if the resource is below /content/mails or so. Such a mechanism could really be helpful for users that have no possibility to modify existing content. We have discussed and abandoned this idea before, because we could not find a generic and easy way of defining which part of the path would influence script selection. If you can provide us with such a definition, we would re-evaluate our findings. Regards Felix Cheers Michael On 2/15/08, Felix Meschberger [EMAIL PROTECTED] wrote: Hi Michael, I just updated the jcr/resource module to create a sling:Resource mixin node type, which defines a sling:resourceType property as a String. You may attach this mixin node type to your mail node and set resource type accordingly. This gives you the full flexibility to render your mail specifically. Alternatively, of course, you may create a servlet or script for the nt:file resource type. But this has the advantage that all nt:file nodes regardless of whether they are actually mail or not will be rendered by that servlet or script. The first option is probably better. Regards Felix Am Freitag, den 15.02.2008, 11:52 +0100 schrieb Michael Marth: Hi, I have an existing content model and want to build a sling app on top. The model is Jukka Zitting's mail model he coded for James (see [1]). One mail is stored as: nt:file |-jcr:content (unstructured) |- from (string) |- to (string) |- jcr:data (binary) ... In order to display a mail via Sling I added a property sling:resourceType to the jcr:content sub node (because I could not add it to nt:file). My URL now looks something like: http://localhost:/content/.../emailtitle/jcr:content or http://localhost:/content/.../emailtitle but in both cases the binary jcr:data is returned directly. Do I have to change my content model or do you guys see a way that I can access my mail resources and have a script being executed? Thanks for hints Cheers Michael [1] http://dev.day.com/microsling/content/blogs/main/jcrmail.html
