[jira] Commented: (SLING-60) URI path split is content dependent
[ https://issues.apache.org/jira/browse/SLING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535432 ] Bertrand Delacretaz commented on SLING-60: -- Ok, I see your point...I started looking at the Sling code before implementing this yesterday and then got lazy ;-) I'm not sure if resolving the Resource in a Filter is the best idea though: how about making the ResourceResolver a first-class Sling API citizen instead, and calling that from the SlingRequestContext on-demand, when the Resource of the RequestPathInfo is accessed? This might make it easier to make the ResourceResolver a plugin (in Sling OSGi mostly), and might also make the code clearer to follow? And I agree that the ResourceResolver must provide the URI parts after resolving the resource. > URI path split is content dependent > --- > > Key: SLING-60 > URL: https://issues.apache.org/jira/browse/SLING-60 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger > Fix For: 2.0.0 > > > I have a conceptual issue with the SlingRequestPathInfoParser because the > idea of cutting an URI path into pieces is different and the > SlingRequestPathInfoParser just does not have enough knowledge to break the > URI path apart. > The initial intent of breaking the URI apart such, that the resource path is > the the longest prefix of the URI path matching a repository item (I think we > should move to enabling addressing items and not just nodes...) and the rest > of the breakup depends on the first part. > So a simple implementation would be to cut off pieces of the URI path from > the end at dots and slashes until a repository item may be addressed. What > has been cut off is then further treated like this: >* Any pieces separated by a dot from the path in the same path segement > are considered the > selectors and extension. >* All pieces together after the last segement of the item path make up the > suffix. > Examples: > /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken > apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, > suffix=/some/suffix.pdf > > /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c > would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], > ext=html, suffix=/some/suffix.pdf > > Simple string operations cannot account for this subtelity. For this reason I > propse to drop the SlingRequestPathInfoParser class and implement the split > up in the ResourceResolverFilter or an abstract base class thereoff. > See also the ContentResolverFilter in the Sling Core project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-60) URI path split is content dependent
Could we please discuss things in the mailing list and not in Jira? This would make it much easier for others to see what is discussed and participate. Thanks Carsten Bertrand Delacretaz (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/SLING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535432 > ] > > Bertrand Delacretaz commented on SLING-60: > -- > > Ok, I see your point...I started looking at the Sling code before > implementing this yesterday and then got lazy ;-) > > I'm not sure if resolving the Resource in a Filter is the best idea though: > how about making the ResourceResolver a first-class Sling API citizen > instead, and calling that from the SlingRequestContext on-demand, when the > Resource of the RequestPathInfo is accessed? > > This might make it easier to make the ResourceResolver a plugin (in Sling > OSGi mostly), and might also make the code clearer to follow? > > And I agree that the ResourceResolver must provide the URI parts after > resolving the resource. > >> URI path split is content dependent >> --- >> >> Key: SLING-60 >> URL: https://issues.apache.org/jira/browse/SLING-60 >> Project: Sling >> Issue Type: Improvement >> Components: microsling >>Reporter: Felix Meschberger >> Fix For: 2.0.0 >> >> >> I have a conceptual issue with the SlingRequestPathInfoParser because the >> idea of cutting an URI path into pieces is different and the >> SlingRequestPathInfoParser just does not have enough knowledge to break the >> URI path apart. >> The initial intent of breaking the URI apart such, that the resource path is >> the the longest prefix of the URI path matching a repository item (I think >> we should move to enabling addressing items and not just nodes...) and the >> rest of the breakup depends on the first part. >> So a simple implementation would be to cut off pieces of the URI path from >> the end at dots and slashes until a repository item may be addressed. What >> has been cut off is then further treated like this: >>* Any pieces separated by a dot from the path in the same path segement >> are considered the >> selectors and extension. >>* All pieces together after the last segement of the item path make up >> the suffix. >> Examples: >> /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken >> apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, >> suffix=/some/suffix.pdf >> >> /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c >> would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], >> ext=html, suffix=/some/suffix.pdf >> >> Simple string operations cannot account for this subtelity. For this reason >> I propse to drop the SlingRequestPathInfoParser class and implement the >> split up in the ResourceResolverFilter or an abstract base class thereoff. >> See also the ContentResolverFilter in the Sling Core project. > -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (SLING-60) URI path split is content dependent
[ https://issues.apache.org/jira/browse/SLING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535433 ] Bertrand Delacretaz commented on SLING-60: -- (moving the discussion to the dev list) > URI path split is content dependent > --- > > Key: SLING-60 > URL: https://issues.apache.org/jira/browse/SLING-60 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger > Fix For: 2.0.0 > > > I have a conceptual issue with the SlingRequestPathInfoParser because the > idea of cutting an URI path into pieces is different and the > SlingRequestPathInfoParser just does not have enough knowledge to break the > URI path apart. > The initial intent of breaking the URI apart such, that the resource path is > the the longest prefix of the URI path matching a repository item (I think we > should move to enabling addressing items and not just nodes...) and the rest > of the breakup depends on the first part. > So a simple implementation would be to cut off pieces of the URI path from > the end at dots and slashes until a repository item may be addressed. What > has been cut off is then further treated like this: >* Any pieces separated by a dot from the path in the same path segement > are considered the > selectors and extension. >* All pieces together after the last segement of the item path make up the > suffix. > Examples: > /a/b/c.print.a4.html/some/suffix.pdf with an item at /a/b/c would be broken > apart as resourcePath=/a/b/c, selectors=[print,a4], ext=html, > suffix=/some/suffix.pdf > > /a/b.special/c.print.a4.html/some/suffix.pdf with an item at /a/b.special/c > would be broken apart as resourcePath=/a/b.special/c, selectors=[print,a4], > ext=html, suffix=/some/suffix.pdf > > Simple string operations cannot account for this subtelity. For this reason I > propse to drop the SlingRequestPathInfoParser class and implement the split > up in the ResourceResolverFilter or an abstract base class thereoff. > See also the ContentResolverFilter in the Sling Core project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-60) URI path split is content dependent
On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Could we please discuss things in the mailing list and not in Jira... Sure, let me restate what I said in JIRA-60 here: I agree with what Felix says in JIRA-60, about the RequestPathInfo (selectors, extension, suffix, etc) being dependent on the way the Resource is resolved. So the current microsling SlingRequestPathInfoParser is wrong in its current state. But I'm not sure if resolving the Resource in a Filter is the best idea: how about making the ResourceResolver a first-class Sling API citizen instead, and calling that from the SlingRequestContext on-demand, when the Resource of the RequestPathInfo is accessed? This might make it easier to make the ResourceResolver a plugin (in Sling OSGi mostly), and might also make the code clearer to follow? I think Filters are good for either manipulating the Request before processing it, or enhancing the Request attributes with "small" things that are not always needed, like the detected Locale for example. But something as fundamental as finding the Resource to act on (and computing the RequestPathInfo) should not be "hidden" in a Filter, IMHO. -Bertrand
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
Hi guys, > I agree, that we might want to wait for a real-life request. > On the other hand it is not only the end-users fault if not the correct > methods could be used, though browsers are probably the major number of > culprits. Many times it is just a question of firewall limitation which > can by no means be circumvented by the casual user on the internet ... I agree, aswell. Generally, I guess what I would be excited to use from a microsling user perspective is: (a) a flexible and very easily extensible GET that does all my different renditions of a content node on the server (b) a clean PUT and DELETE that operates as expected, which is probably triggered through some XHR based js lib in the browser. (c) a functionally powerful POST that (amongst other things) allows me to trigger any content repository modification through a straight html-form in a browser. Generally, this means that as a user I am less interested in tweaking the "writing" mechanisms to the repository, since they are sufficiently simple and complete, while the rendering/presentation is very user and usecase specific. I would personally stay away from any of the mentioned "HTTP method simulation" techniques (until requested). Personally I would assume that there are requirements such as dealing versioning operations or batching up multiple modifications that (short of implementing WebDAV and its ugly cousins) would go into the "powerful" ootb POST handling. Personally I could see a powerful POST handling to be very similar to what Bertrand and I use in http://www.day.com/maven/rjax/ Thoughts? regards, david
Re: [jira] Commented: (SLING-60) URI path split is content dependent
I completely agree with respect to not using a Filter for ResourceResolution. Lets make the ResourceResolver a service called by the SlingRequestContext on demand (btw, the SlingRequestContext must then probably have a reference to the request, right ?). Regards Felix Am Mittwoch, den 17.10.2007, 09:11 +0200 schrieb Bertrand Delacretaz: > On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Could we please discuss things in the mailing list and not in Jira... > > Sure, let me restate what I said in JIRA-60 here: > > I agree with what Felix says in JIRA-60, about the RequestPathInfo > (selectors, extension, suffix, etc) being dependent on the way the > Resource is resolved. So the current microsling > SlingRequestPathInfoParser is wrong in its current state. > > But I'm not sure if resolving the Resource in a Filter is the best > idea: how about making the ResourceResolver a first-class Sling API > citizen instead, and calling that from the SlingRequestContext > on-demand, when the Resource of the RequestPathInfo is accessed? > > This might make it easier to make the ResourceResolver a plugin (in > Sling OSGi mostly), and might also make the code clearer to follow? > > I think Filters are good for either manipulating the Request before > processing it, or enhancing the Request attributes with "small" things > that are not always needed, like the detected Locale for example. > > But something as fundamental as finding the Resource to act on (and > computing the RequestPathInfo) should not be "hidden" in a Filter, > IMHO. > > -Bertrand
To Filter or not to Filter
Hi all, Currently, we love using filtering in both Sling and microsling: Every part of request processing is implemented using a filter. This was not always the case: In the days when Sling was still private, there was no filtering at all. Probably we must come to a mix of both: There are some tasks, which have to be executed all the times and there are some tasks which may or may not be executed. Examples of the former are authentication, proper error handling, resource resolution and servlet/script resolution. Examples of the latter are locale resolution, default setting of the response content type etc. So, for microsling, I propose to not implement resource resolution as a filter, in fact leaving default response content type setting the only filtering task (currently). For Sling I propose to not implement filtering for authentication (replace AuthenticationFilter by a service called directly), errorhandler (replace ErrorHandlerFilter), contentresolution (replace ContentResolverFilter) and component resolution (replace ComponentResolver). These tasks are always executed in the listed order by the Sling request processor. After the component is resolved the registered filters are called and finally the component itself is called. WDYT ? Regards Felix
[jira] Closed: (SLING-57) Resource: retarget the data to be the mapped object and add Item for the addressed repository Item
[ https://issues.apache.org/jira/browse/SLING-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-57. -- Resolution: Fixed This has been implemented and the issue can be closed. > Resource: retarget the data to be the mapped object and add Item for the > addressed repository Item > -- > > Key: SLING-57 > URL: https://issues.apache.org/jira/browse/SLING-57 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > As discussed on the devlist [1] we need both the (optionally) mapped Java > object and the JCR item in the Resource. So the getData() method should be > redefined as returning the mapped object or null if there is no mapping of > any kind and getItem() to return the JCR item or null if there is no JCR item > for the resource. > [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00335.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: To Filter or not to Filter
Felix Meschberger wrote: > Hi all, > > Currently, we love using filtering in both Sling and microsling: Every > part of request processing is implemented using a filter. This was not > always the case: In the days when Sling was still private, there was no > filtering at all. > > Probably we must come to a mix of both: There are some tasks, which have > to be executed all the times and there are some tasks which may or may > not be executed. Examples of the former are authentication, proper error > handling, resource resolution and servlet/script resolution. Examples of > the latter are locale resolution, default setting of the response > content type etc. > > So, for microsling, I propose to not implement resource resolution as a > filter, in fact leaving default response content type setting the only > filtering task (currently). > > For Sling I propose to not implement filtering for authentication > (replace AuthenticationFilter by a service called directly), > errorhandler (replace ErrorHandlerFilter), contentresolution (replace > ContentResolverFilter) and component resolution (replace > ComponentResolver). These tasks are always executed in the listed order > by the Sling request processor. After the component is resolved the > registered filters are called and finally the component itself is > called. > > WDYT ? > Hmm, filters have the great advantage being very flexible. You can combine them in any order, make them optional etc. On the other hand I agree that some things are required for sling to work, so a filter doesn't seem quiet right. I agree for resource and content resolution. But I'm not sure about authentication. Having a filter which does the authentication is very transparent. If we are using the servlet filter interface for these filters, its easy to use other authentication mechanisms like for example spring authentication (aka acegi) which is based on servlet filters as well. So for now, I personally tend to go with filters except where something is really required for Sling core to work. There we could use an explicit service instead. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: To Filter or not to Filter
I have the same feeling here. Filter are flexible. Specially for making processing like authencitation I would like to say that microsling is very simple to understand as it is. I like the combinaison of the different serlvets & filters. Cool & great job. On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Felix Meschberger wrote: > > Hi all, > > > > Currently, we love using filtering in both Sling and microsling: Every > > part of request processing is implemented using a filter. This was not > > always the case: In the days when Sling was still private, there was no > > filtering at all. > > > > Probably we must come to a mix of both: There are some tasks, which have > > to be executed all the times and there are some tasks which may or may > > not be executed. Examples of the former are authentication, proper error > > handling, resource resolution and servlet/script resolution. Examples of > > the latter are locale resolution, default setting of the response > > content type etc. > > > > So, for microsling, I propose to not implement resource resolution as a > > filter, in fact leaving default response content type setting the only > > filtering task (currently). > > > > For Sling I propose to not implement filtering for authentication > > (replace AuthenticationFilter by a service called directly), > > errorhandler (replace ErrorHandlerFilter), contentresolution (replace > > ContentResolverFilter) and component resolution (replace > > ComponentResolver). These tasks are always executed in the listed order > > by the Sling request processor. After the component is resolved the > > registered filters are called and finally the component itself is > > called. > > > > WDYT ? > > > Hmm, filters have the great advantage being very flexible. You can > combine them in any order, make them optional etc. On the other hand I > agree that some things are required for sling to work, so a filter > doesn't seem quiet right. > > I agree for resource and content resolution. But I'm not sure about > authentication. Having a filter which does the authentication is very > transparent. If we are using the servlet filter interface for these > filters, its easy to use other authentication mechanisms like for > example spring authentication (aka acegi) which is based on servlet > filters as well. > So for now, I personally tend to go with filters except where something > is really required for Sling core to work. There we could use an > explicit service instead. > > Carsten > -- > Carsten Ziegeler > [EMAIL PROTECTED] >
Re: [jira] Commented: (SLING-60) URI path split is content dependent
On 10/17/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...Lets make the ResourceResolver a service called by > the SlingRequestContext on demand... cool > ...btw, the SlingRequestContext must > then probably have a reference to the request, right ?) Yes, agreed. -Bertrand
[jira] Assigned: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-61: - Assignee: Carsten Ziegeler > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-61) Rendering of references within the repository
Rendering of references within the repository - Key: SLING-61 URL: https://issues.apache.org/jira/browse/SLING-61 Project: Sling Issue Type: New Feature Components: Core Reporter: Carsten Ziegeler If compound content is rendered (a node and its children), it would be good to provide a mechanism which references other trees in the repository. Example: Node A + header + footer Node B + content Node C + content When node B or C are rendered, the header and footer of node A should be rendered as well. A new node type sling:Reference with a path property will be introduced to allow such references: Node B + header [sling:Reference (path = /A/header)] + content + footer [sling:Reference (path = /A/footer)] A new content and component (ReferenceContent and ReferenceComponent) will be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: To Filter or not to Filter
On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ...So for now, I personally tend to go with filters except where something > is really required for Sling core to work. There we could use an > explicit service instead I think that's a very good criteria: if something's always required by Sling, make it a service, *and* make sure its interface exists in the api package, to make it well visible. I agree that authentication might be better handled by a filter, as it's a common way of doing that. -Bertrand
[jira] Closed: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-61. - Resolution: Fixed Add a new node type and corresponding components/content. > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535546 ] Tobias Bocanegra commented on SLING-61: --- i don't see why this is necessary. it just makes script execution more magic. if you need to include a header or a footer, just include this in your script. further, for larger sites, you would never 'copy' add the header and footer references to every page but use some sort of inheritance. suggest to remove this. > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-62) revert changes of SLING-61
revert changes of SLING-61 -- Key: SLING-62 URL: https://issues.apache.org/jira/browse/SLING-62 Project: Sling Issue Type: Sub-task Reporter: Tobias Bocanegra (somehow i can't reopen the bug, thus creating this subtask) as commented in SLING-61 is suggest to remove this component unless someone can give a good real life example why we need this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535552 ] Felix Meschberger commented on SLING-61: > suggest to remove this. -1 Maybe the use case does not convince you, but I would leave this in for the moment. It does not hurt and it does not make scrtip execution more magic, because it is very clear, what is going on: The ReferenceComponent just dispatches to the reference target. > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-62) revert changes of SLING-61
[ https://issues.apache.org/jira/browse/SLING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-62. -- Resolution: Won't Fix This is issue is void > revert changes of SLING-61 > -- > > Key: SLING-62 > URL: https://issues.apache.org/jira/browse/SLING-62 > Project: Sling > Issue Type: Sub-task >Reporter: Tobias Bocanegra > > (somehow i can't reopen the bug, thus creating this subtask) > as commented in SLING-61 is suggest to remove this component unless someone > can give a good real life example why we need this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-62) revert changes of SLING-61
[ https://issues.apache.org/jira/browse/SLING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535554 ] Felix Meschberger commented on SLING-62: As suggest in my comment to SLING-61, I would leave the Reference stuff in for the moment and see where it leads. To do what Tobias wants, I close this as wontfix and reopen SLING-61 for further consideration. > revert changes of SLING-61 > -- > > Key: SLING-62 > URL: https://issues.apache.org/jira/browse/SLING-62 > Project: Sling > Issue Type: Sub-task >Reporter: Tobias Bocanegra > > (somehow i can't reopen the bug, thus creating this subtask) > as commented in SLING-61 is suggest to remove this component unless someone > can give a good real life example why we need this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened SLING-61: Reopen the issue for further consideration. Carsten, could you please comment ? Thanks. > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: To Filter or not to Filter
Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler: > I agree for resource and content resolution. But I'm not sure about > authentication. Having a filter which does the authentication is very > transparent. If we are using the servlet filter interface for these > filters, its easy to use other authentication mechanisms like for > example spring authentication (aka acegi) which is based on servlet > filters as well. > So for now, I personally tend to go with filters except where something > is really required for Sling core to work. There we could use an > explicit service instead. Not sure, whether this is the level authentication we require. Sling's main purpose, which is also made strongly visible through the upcoming Resource interface, is to provide a web application front-end to JCR repositories. As such, I assume, that the JCR repository will be used for authentication and access control purposes. As such, the only moving target of authentication is the question on how to extract credential data from the request to use it as input to the JCR Repository.login method. Currently Sling has an AuthenticationFilter which makes use of AuthenticationHandler services (only HTTP Header Authentication is implemented for now) to get the credentials or request the credentials from the client. How authentication is handled in the repository is completely out-of-scope for Sling. This is why I proposed to not use a filter for authentication. Regards Felix
[jira] Commented: (SLING-61) Rendering of references within the repository
[ https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535564 ] Bertrand Delacretaz commented on SLING-61: -- > Node B > + header [sling:Reference (path = /A/header)] > + content > + footer [sling:Reference (path = /A/footer)] IMHO this mixes concerns: I assume Node B is part of the *content*, yet this header/footer business is clearly *presentation* stuff. Having to add nodes in the content to define how it is rendered sounds terribly wrong to me: adding a header/footer when rendering Node B is clearly a *Component* concern. > Rendering of references within the repository > - > > Key: SLING-61 > URL: https://issues.apache.org/jira/browse/SLING-61 > Project: Sling > Issue Type: New Feature > Components: Core >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > If compound content is rendered (a node and its children), it would be good > to provide a mechanism which references other trees in the repository. > Example: > Node A >+ header >+ footer > Node B >+ content > Node C >+ content > When node B or C are rendered, the header and footer of node A should be > rendered as well. > A new node type sling:Reference with a path property will be introduced to > allow such references: > Node B >+ header [sling:Reference (path = /A/header)] >+ content >+ footer [sling:Reference (path = /A/footer)] > A new content and component (ReferenceContent and ReferenceComponent) will be > added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (SLING-61) Rendering of references within the repository
Okay, the main idea is to have some kind of references which allows to create virtual trees in a transparent way. I thought that this could be useful. :) Let's consider an example with a page node which has a header, footer and content node. Rendering of the page node is always the same (header, content, footer). Now, with these references it's possible to reference parts of the page from a template or master page. And the page rendering does not need to know these things. So, that's the basic idea - now, there might be better/other ways to handle such things, but they are not transparent. Carsten Felix Meschberger (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Felix Meschberger reopened SLING-61: > > > > Reopen the issue for further consideration. > > Carsten, could you please comment ? Thanks. > >> Rendering of references within the repository >> - >> >> Key: SLING-61 >> URL: https://issues.apache.org/jira/browse/SLING-61 >> Project: Sling >> Issue Type: New Feature >> Components: Core >>Reporter: Carsten Ziegeler >>Assignee: Carsten Ziegeler >> >> If compound content is rendered (a node and its children), it would be good >> to provide a mechanism which references other trees in the repository. >> Example: >> Node A >>+ header >>+ footer >> Node B >>+ content >> Node C >>+ content >> When node B or C are rendered, the header and footer of node A should be >> rendered as well. >> A new node type sling:Reference with a path property will be introduced to >> allow such references: >> Node B >>+ header [sling:Reference (path = /A/header)] >>+ content >>+ footer [sling:Reference (path = /A/footer)] >> A new content and component (ReferenceContent and ReferenceComponent) will >> be added. > -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Created: (SLING-63) JCR Mapping does not handle jcrDefaultValue
JCR Mapping does not handle jcrDefaultValue --- Key: SLING-63 URL: https://issues.apache.org/jira/browse/SLING-63 Project: Sling Issue Type: Bug Reporter: Carsten Ziegeler The ClassDescriptorReader does not read a jcrDefaultValue from the xml mapping file and therefore ignore is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-63) JCR Mapping does not handle jcrDefaultValue
[ https://issues.apache.org/jira/browse/SLING-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-63: - Assignee: Carsten Ziegeler > JCR Mapping does not handle jcrDefaultValue > --- > > Key: SLING-63 > URL: https://issues.apache.org/jira/browse/SLING-63 > Project: Sling > Issue Type: Bug >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > The ClassDescriptorReader does not read a jcrDefaultValue from the xml > mapping file and therefore ignore is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (SLING-61) Rendering of references within the repository
On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ...Let's consider an example with a page node which has a header, footer > and content node. Rendering of the page node is always the same (header, > content, footer). Now, with these references it's possible to reference > parts of the page from a template or master page. And the page rendering > does not need to know these things IIUC this means you want to put nodes in the content, which are here just to define how that content is rendered? Sounds like I'd get a slap on my fingers if I did that in school ;-) -Bertrand
Re: To Filter or not to Filter
i disagree...eg. when running in a appserver that does authentication sling does not need the default http auth filter, but maybe a jaas-auth filter or sso filter or whatsoever. bottom line: the authentication mechanism needs to be configurable. regards, toby On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Felix Meschberger wrote: > > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler: > >> I agree for resource and content resolution. But I'm not sure about > >> authentication. Having a filter which does the authentication is very > >> transparent. If we are using the servlet filter interface for these > >> filters, its easy to use other authentication mechanisms like for > >> example spring authentication (aka acegi) which is based on servlet > >> filters as well. > >> So for now, I personally tend to go with filters except where something > >> is really required for Sling core to work. There we could use an > >> explicit service instead. > > > > Not sure, whether this is the level authentication we require. Sling's > > main purpose, which is also made strongly visible through the upcoming > > Resource interface, is to provide a web application front-end to JCR > > repositories. As such, I assume, that the JCR repository will be used > > for authentication and access control purposes. > > > > As such, the only moving target of authentication is the question on how > > to extract credential data from the request to use it as input to the > > JCR Repository.login method. Currently Sling has an AuthenticationFilter > > which makes use of AuthenticationHandler services (only HTTP Header > > Authentication is implemented for now) to get the credentials or request > > the credentials from the client. How authentication is handled in the > > repository is completely out-of-scope for Sling. > > > > This is why I proposed to not use a filter for authentication. > > > Yes, you're right - so no filter for authentication. > > Carsten > > -- > Carsten Ziegeler > [EMAIL PROTECTED] > -- -< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 ---< http://www.day.com >---
Re: To Filter or not to Filter
Felix Meschberger wrote: > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler: >> I agree for resource and content resolution. But I'm not sure about >> authentication. Having a filter which does the authentication is very >> transparent. If we are using the servlet filter interface for these >> filters, its easy to use other authentication mechanisms like for >> example spring authentication (aka acegi) which is based on servlet >> filters as well. >> So for now, I personally tend to go with filters except where something >> is really required for Sling core to work. There we could use an >> explicit service instead. > > Not sure, whether this is the level authentication we require. Sling's > main purpose, which is also made strongly visible through the upcoming > Resource interface, is to provide a web application front-end to JCR > repositories. As such, I assume, that the JCR repository will be used > for authentication and access control purposes. > > As such, the only moving target of authentication is the question on how > to extract credential data from the request to use it as input to the > JCR Repository.login method. Currently Sling has an AuthenticationFilter > which makes use of AuthenticationHandler services (only HTTP Header > Authentication is implemented for now) to get the credentials or request > the credentials from the client. How authentication is handled in the > repository is completely out-of-scope for Sling. > > This is why I proposed to not use a filter for authentication. > Yes, you're right - so no filter for authentication. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-63) JCR Mapping does not handle jcrDefaultValue
[ https://issues.apache.org/jira/browse/SLING-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-63. - Resolution: Fixed > JCR Mapping does not handle jcrDefaultValue > --- > > Key: SLING-63 > URL: https://issues.apache.org/jira/browse/SLING-63 > Project: Sling > Issue Type: Bug >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > The ClassDescriptorReader does not read a jcrDefaultValue from the xml > mapping file and therefore ignore is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: To Filter or not to Filter
Am Mittwoch, den 17.10.2007, 16:49 +0200 schrieb Tobias Bocanegra: > i disagree...eg. when running in a appserver that does authentication > sling does not need the default http auth filter, but maybe a > jaas-auth filter or sso filter or whatsoever. > > bottom line: the authentication mechanism needs to be configurable. This is not question here. Sling is in fact built such, that the method of building the credentials is configurable and filters is not the only way how sling mechanisms can be "configured" in a flexible way. So in the case of authentication: We will have an Authentication service used by Sling, which in turn may make use of additional helpers. Both the helpers can be added/removed at will and the Authentication service may be implemented however we wish. This is something different than whether we call the authentication service directly or as part of some filtering. Regards Felix > regards, toby > > On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Felix Meschberger wrote: > > > Am Mittwoch, den 17.10.2007, 09:39 +0200 schrieb Carsten Ziegeler: > > >> I agree for resource and content resolution. But I'm not sure about > > >> authentication. Having a filter which does the authentication is very > > >> transparent. If we are using the servlet filter interface for these > > >> filters, its easy to use other authentication mechanisms like for > > >> example spring authentication (aka acegi) which is based on servlet > > >> filters as well. > > >> So for now, I personally tend to go with filters except where something > > >> is really required for Sling core to work. There we could use an > > >> explicit service instead. > > > > > > Not sure, whether this is the level authentication we require. Sling's > > > main purpose, which is also made strongly visible through the upcoming > > > Resource interface, is to provide a web application front-end to JCR > > > repositories. As such, I assume, that the JCR repository will be used > > > for authentication and access control purposes. > > > > > > As such, the only moving target of authentication is the question on how > > > to extract credential data from the request to use it as input to the > > > JCR Repository.login method. Currently Sling has an AuthenticationFilter > > > which makes use of AuthenticationHandler services (only HTTP Header > > > Authentication is implemented for now) to get the credentials or request > > > the credentials from the client. How authentication is handled in the > > > repository is completely out-of-scope for Sling. > > > > > > This is why I proposed to not use a filter for authentication. > > > > > Yes, you're right - so no filter for authentication. > > > > Carsten > > > > -- > > Carsten Ziegeler > > [EMAIL PROTECTED] > > > >
[jira] Created: (SLING-64) Refactor Servlets and Script resolution
Refactor Servlets and Script resolution --- Key: SLING-64 URL: https://issues.apache.org/jira/browse/SLING-64 Project: Sling Issue Type: Improvement Components: microsling Reporter: Felix Meschberger Fix For: 2.0.0 microsling currently defines a SlingServlet interface which has a canProcess method used to decide whether a servlet is capable of handling a request or not. I think, this mechanism will not scale well if we add more script engines or more servlets. As a first step towards a simpler approach, I propose the following: * Merge the DefaultSlingServlet and the SlingPostServlet to a single DefaultSlingServlet * Replace Rhino and Velocity servlets by respective ScriptEngines (and define the interface for that) * Refactor the SlingScriptResolver such that after resolving the script, it is also evaluated through a ScriptEngine * Refactor MicroSlingServlet such, that (1) check for a servlet by resource type (2) try to evaluate a script (3) fall back to the DefaultSlingServlet * Also in the MicroSlingServlet register servlets by type (currently there are none of course) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-65) Add RequestParameter abstraction
[ https://issues.apache.org/jira/browse/SLING-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-65: --- Component/s: microsling > Add RequestParameter abstraction > > > Key: SLING-65 > URL: https://issues.apache.org/jira/browse/SLING-65 > Project: Sling > Issue Type: New Feature > Components: microsling >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > As discussed on the list add the RequestParameter abstraction to microsling. > microsling will just replicate the parameters provided by the Servlet API and > will also not support any parameter encoding. This is implemented in the real > Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-65) Add RequestParameter abstraction
Add RequestParameter abstraction Key: SLING-65 URL: https://issues.apache.org/jira/browse/SLING-65 Project: Sling Issue Type: New Feature Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 As discussed on the list add the RequestParameter abstraction to microsling. microsling will just replicate the parameters provided by the Servlet API and will also not support any parameter encoding. This is implemented in the real Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-64) Refactor Servlets and Script resolution
[ https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-64: --- Attachment: SLING-64.patch Proposed changes > Refactor Servlets and Script resolution > --- > > Key: SLING-64 > URL: https://issues.apache.org/jira/browse/SLING-64 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger > Fix For: 2.0.0 > > Attachments: SLING-64.patch > > > microsling currently defines a SlingServlet interface which has a canProcess > method used to decide whether a servlet is capable of handling a request or > not. I think, this mechanism will not scale well if we add more script > engines or more servlets. > As a first step towards a simpler approach, I propose the following: >* Merge the DefaultSlingServlet and the SlingPostServlet to a single > DefaultSlingServlet >* Replace Rhino and Velocity servlets by respective ScriptEngines (and > define the interface for that) >* Refactor the SlingScriptResolver such that after resolving the script, > it is also evaluated through a ScriptEngine >* Refactor MicroSlingServlet such, that > (1) check for a servlet by resource type > (2) try to evaluate a script > (3) fall back to the DefaultSlingServlet >* Also in the MicroSlingServlet register servlets by type (currently there > are none of course) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-65) Add RequestParameter abstraction
[ https://issues.apache.org/jira/browse/SLING-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-65. -- Resolution: Fixed Added RequestParameter and RequestParameterMap interfaces and getter to SlingRequestContext in Rev. 585568 > Add RequestParameter abstraction > > > Key: SLING-65 > URL: https://issues.apache.org/jira/browse/SLING-65 > Project: Sling > Issue Type: New Feature > Components: microsling >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > As discussed on the list add the RequestParameter abstraction to microsling. > microsling will just replicate the parameters provided by the Servlet API and > will also not support any parameter encoding. This is implemented in the real > Sling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-64) Refactor Servlets and Script resolution
[
https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535735
]
Torgeir Veimo commented on SLING-64:
How about abstracting this a bit, instead of relying on servlets to say
themselves if they can handle a request, to use factories, or rather, mappers.
A manager would resolve a request to a sling servlet by iterating through its
configured mappers and stopping once a suitable sling servlet is found. If no
mapper resolves a servlet, the default sling servlet is called.
public interface ServletMapper {
public SlingServlet findServlet(SlingServletRequest request, Resource
resource) throws Exception;
}
A configuration file would specify the order of the mappers, along with any
configuration parameters each mapper needs. (A simple digester implementation
would allow configuration parameters to be set using reflection.)
A default mapper which maps to servlets based on url and/or jcr node type or
resource type can be provided which would be sufficient in most cases. For
specific needs a sling api user would implement his own mapper.
Sitemesh uses a similar setup with great success for decorating web pages based
on any combination of url patterns, request parameters and others. I'm using
such a mapper approach successfully in our own prototype crm framework.
> Refactor Servlets and Script resolution
> ---
>
> Key: SLING-64
> URL: https://issues.apache.org/jira/browse/SLING-64
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Felix Meschberger
> Fix For: 2.0.0
>
> Attachments: SLING-64.patch
>
>
> microsling currently defines a SlingServlet interface which has a canProcess
> method used to decide whether a servlet is capable of handling a request or
> not. I think, this mechanism will not scale well if we add more script
> engines or more servlets.
> As a first step towards a simpler approach, I propose the following:
>* Merge the DefaultSlingServlet and the SlingPostServlet to a single
> DefaultSlingServlet
>* Replace Rhino and Velocity servlets by respective ScriptEngines (and
> define the interface for that)
>* Refactor the SlingScriptResolver such that after resolving the script,
> it is also evaluated through a ScriptEngine
>* Refactor MicroSlingServlet such, that
> (1) check for a servlet by resource type
> (2) try to evaluate a script
> (3) fall back to the DefaultSlingServlet
>* Also in the MicroSlingServlet register servlets by type (currently there
> are none of course)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-66) Create a microsling jar artifact in addition the the war file
Create a microsling jar artifact in addition the the war file - Key: SLING-66 URL: https://issues.apache.org/jira/browse/SLING-66 Project: Sling Issue Type: Improvement Components: microsling Reporter: Bertrand Delacretaz Priority: Minor It'd be useful for the microsling build to generate a jar artifact in addition to the war, to make it easier for people to use microsling with other JCR repositories besides jackrabbit. microsling expects to find a Repository as a ServletContext attribute named "javax.jcr.Repository", so as long as another Servlet initializes this attribute it should run with any JCR compliant repository. JCR-955 does the same thing for the jackrabbit-webapp module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-66) Create a microsling jar artifact in addition to the war file
[ https://issues.apache.org/jira/browse/SLING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-66: - Summary: Create a microsling jar artifact in addition to the war file (was: Create a microsling jar artifact in addition the the war file) > Create a microsling jar artifact in addition to the war file > > > Key: SLING-66 > URL: https://issues.apache.org/jira/browse/SLING-66 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Priority: Minor > > It'd be useful for the microsling build to generate a jar artifact in > addition to the war, to make it easier for people to use microsling with > other JCR repositories besides jackrabbit. > microsling expects to find a Repository as a ServletContext attribute named > "javax.jcr.Repository", so as long as another Servlet initializes this > attribute it should run with any JCR compliant repository. > JCR-955 does the same thing for the jackrabbit-webapp module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-66) Create a microsling jar artifact in addition to the war file
[ https://issues.apache.org/jira/browse/SLING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-66. -- Resolution: Fixed Fixed in revision 585881 > Create a microsling jar artifact in addition to the war file > > > Key: SLING-66 > URL: https://issues.apache.org/jira/browse/SLING-66 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Priority: Minor > > It'd be useful for the microsling build to generate a jar artifact in > addition to the war, to make it easier for people to use microsling with > other JCR repositories besides jackrabbit. > microsling expects to find a Repository as a ServletContext attribute named > "javax.jcr.Repository", so as long as another Servlet initializes this > attribute it should run with any JCR compliant repository. > JCR-955 does the same thing for the jackrabbit-webapp module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (SLING-61) Rendering of references within the repository
Bertrand Delacretaz wrote: > On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > >> ...Let's consider an example with a page node which has a header, footer >> and content node. Rendering of the page node is always the same (header, >> content, footer). Now, with these references it's possible to reference >> parts of the page from a template or master page. And the page rendering >> does not need to know these things > > IIUC this means you want to put nodes in the content, which are here > just to define how that content is rendered? Sounds like I'd get a > slap on my fingers if I did that in school ;-) > :) Hmm, no, it's a little different I think/hope. Let's forget about this page/header/footer example which might be a bad one for this feature. Perhaps this reference thing doesn't make sense and I'm totally off track, but what about creating artifical views for lets say document collections. So, you have a node storing all documents as sub nodes. Now, you want to make a view on these documents containing just a bunch of them. With the references, you create a "view node" containing several reference nodes and are done. Does this make sense? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Reopened: (SLING-61) Rendering of references within the repository
I have another use case which comes from a real-world CMS :-) Consider you have a pages containing paragraphs of text. There may be crossreferences of even shared paragraphs. It would be nice, if instead of copying the shared paragraph we could just refer to it. Another use case probably is content inheritance on another level: Consider a system for where we have support for multiple languages. We would have a tree for the default language and additional trees per language. Instead of just copying the complete default language tree for each additional language, we could just create page nodes in the languages and add references to the contents of the default language tree. Both use cases will of course define and properly handle the case of updating the content: The reference paragraph case might just edit to target paragraph while the multi language case might create a (partial) copy on write. Regards Felix Am Mittwoch, den 17.10.2007, 16:21 +0200 schrieb Carsten Ziegeler: > Okay, the main idea is to have some kind of references which allows to > create virtual trees in a transparent way. I thought that this could be > useful. :) > > Let's consider an example with a page node which has a header, footer > and content node. Rendering of the page node is always the same (header, > content, footer). Now, with these references it's possible to reference > parts of the page from a template or master page. And the page rendering > does not need to know these things. > > So, that's the basic idea - now, there might be better/other ways to > handle such things, but they are not transparent. > > Carsten > > > Felix Meschberger (JIRA) wrote: > > [ > > https://issues.apache.org/jira/browse/SLING-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > > > Felix Meschberger reopened SLING-61: > > > > > > > > Reopen the issue for further consideration. > > > > Carsten, could you please comment ? Thanks. > > > >> Rendering of references within the repository > >> - > >> > >> Key: SLING-61 > >> URL: https://issues.apache.org/jira/browse/SLING-61 > >> Project: Sling > >> Issue Type: New Feature > >> Components: Core > >>Reporter: Carsten Ziegeler > >>Assignee: Carsten Ziegeler > >> > >> If compound content is rendered (a node and its children), it would be > >> good to provide a mechanism which references other trees in the repository. > >> Example: > >> Node A > >>+ header > >>+ footer > >> Node B > >>+ content > >> Node C > >>+ content > >> When node B or C are rendered, the header and footer of node A should be > >> rendered as well. > >> A new node type sling:Reference with a path property will be introduced to > >> allow such references: > >> Node B > >>+ header [sling:Reference (path = /A/header)] > >>+ content > >>+ footer [sling:Reference (path = /A/footer)] > >> A new content and component (ReferenceContent and ReferenceComponent) will > >> be added. > > > >
Re: svn commit: r585881 - /incubator/sling/whiteboard/microsling/pom.xml
Wouldn't it be easier to just configure the JAR plugin to the project
instead of the antrun and attach-artifacts plugin ? IIRC the jar plugin
creates an attachment if it is not run as the main packager of the
project or you may be able to configure the plugin correctly.
Regards
Felix
Am Donnerstag, den 18.10.2007, 06:13 + schrieb
[EMAIL PROTECTED]:
> Author: bdelacretaz
> Date: Wed Oct 17 23:13:56 2007
> New Revision: 585881
>
> URL: http://svn.apache.org/viewvc?rev=585881&view=rev
> Log:
> SLING-66 : Create a microsling jar artifact in addition to the war file
>
> Modified:
> incubator/sling/whiteboard/microsling/pom.xml
>
> Modified: incubator/sling/whiteboard/microsling/pom.xml
> URL:
> http://svn.apache.org/viewvc/incubator/sling/whiteboard/microsling/pom.xml?rev=585881&r1=585880&r2=585881&view=diff
> ==
> --- incubator/sling/whiteboard/microsling/pom.xml (original)
> +++ incubator/sling/whiteboard/microsling/pom.xml Wed Oct 17 23:13:56 2007
> @@ -90,6 +90,46 @@
>
>
>
> +
> +maven-antrun-plugin
> +
> +
> +package
> +
> +
> + +
> destfile="${project.build.directory}/${project.name}-${project.version}.jar"/>
> +
> +
> +
> + run
> +
> +
> +
> +
> +
> +
> +org.codehaus.mojo
> +build-helper-maven-plugin
> +
> +
> +attach-artifacts
> +package
> +
> + attach-artifact
> +
> +
> +
> +
> +
> ${project.build.directory}/${project.name}-${project.version}.jar
> +jar
> +
> +
> +
> +
> +
> +
> +
> org.mortbay.jetty
> maven-jetty-plugin
> 6.1.5
>
>
Re: svn commit: r585881 - /incubator/sling/whiteboard/microsling/pom.xml
On 10/18/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Wouldn't it be easier to just configure the JAR plugin to the project > instead of the antrun and attach-artifacts plugin ? IIRC the jar plugin > creates an attachment if it is not run as the main packager of the > project or you may be able to configure the plugin correctly You're probably right, but I'm not sure how to do that. Feel free to do it if you know how! -Bertrand
[jira] Commented: (SLING-64) Refactor Servlets and Script resolution
[ https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535850 ] Felix Meschberger commented on SLING-64: > ... to use factories, or rather, mappers. Which is at the core of my proposal. Speaking in OSGi terms, Servlets are registered as OSGi services and specify in their service properties the resource type(s) they are willing and able to handle requests for. The Servlet Mapper looks at those registered servlets and selects one on behalf of Sling. And yes, I ultimately suggest dropping the SlingServlet interface including the canProcess method. Not because I do not like it per-se, but I think it will not scale - rotating to a possibly big number of servlets asking each in turn whether it may handle the request may prevent the system from working. But this proposal is just about modifying the general working : not looping through servlets but (1) look for servlets by resource type, (2) check for a script and (3) fall back to a defaul servlet. There will be another issue handling the first step in more detail. > Refactor Servlets and Script resolution > --- > > Key: SLING-64 > URL: https://issues.apache.org/jira/browse/SLING-64 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger > Fix For: 2.0.0 > > Attachments: SLING-64.patch > > > microsling currently defines a SlingServlet interface which has a canProcess > method used to decide whether a servlet is capable of handling a request or > not. I think, this mechanism will not scale well if we add more script > engines or more servlets. > As a first step towards a simpler approach, I propose the following: >* Merge the DefaultSlingServlet and the SlingPostServlet to a single > DefaultSlingServlet >* Replace Rhino and Velocity servlets by respective ScriptEngines (and > define the interface for that) >* Refactor the SlingScriptResolver such that after resolving the script, > it is also evaluated through a ScriptEngine >* Refactor MicroSlingServlet such, that > (1) check for a servlet by resource type > (2) try to evaluate a script > (3) fall back to the DefaultSlingServlet >* Also in the MicroSlingServlet register servlets by type (currently there > are none of course) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-64) Refactor Servlets and Script resolution
[ https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535851 ] Bertrand Delacretaz commented on SLING-64: -- > * Merge the DefaultSlingServlet and the SlingPostServlet to a single > DefaultSlingServlet > * Replace Rhino and Velocity servlets by respective ScriptEngines (and > define the interface for that) > * Refactor the SlingScriptResolver such that after resolving the script, it > is also evaluated through a ScriptEngine > * Refactor MicroSlingServlet such, that >(1) check for a servlet by resource type >(2) try to evaluate a script >(3) fall back to the DefaultSlingServlet > * Also in the MicroSlingServlet register servlets by type (currently there > are none of course) I'm ok with all that, except maybe swapping 2) and 1), i.e. checking for a script first, and if there's none look for a servlet? The rationale would be that servlets implement "standard" mechanisms which can be overridden by scripts. But I'm not sure if that's the best way, we can probably go as you suggest and maybe change if there's a real need to. > Refactor Servlets and Script resolution > --- > > Key: SLING-64 > URL: https://issues.apache.org/jira/browse/SLING-64 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Felix Meschberger > Fix For: 2.0.0 > > Attachments: SLING-64.patch > > > microsling currently defines a SlingServlet interface which has a canProcess > method used to decide whether a servlet is capable of handling a request or > not. I think, this mechanism will not scale well if we add more script > engines or more servlets. > As a first step towards a simpler approach, I propose the following: >* Merge the DefaultSlingServlet and the SlingPostServlet to a single > DefaultSlingServlet >* Replace Rhino and Velocity servlets by respective ScriptEngines (and > define the interface for that) >* Refactor the SlingScriptResolver such that after resolving the script, > it is also evaluated through a ScriptEngine >* Refactor MicroSlingServlet such, that > (1) check for a servlet by resource type > (2) try to evaluate a script > (3) fall back to the DefaultSlingServlet >* Also in the MicroSlingServlet register servlets by type (currently there > are none of course) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (SLING-61) Rendering of references within the repository
On 10/18/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ...So, you have a node storing all documents as sub nodes. Now, you want to > make a view on these documents containing just a bunch of them. With the > references, you create a "view node" containing several reference nodes > and are done Ok, with this example (and Felix's) I agree that this might be useful. The header/footer example was a bit scary though ;-) -Bertrand
