[jira] Updated: (SLING-87) Add Freemarker Scripting Support
[ https://issues.apache.org/jira/browse/SLING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-87: Attachment: freemarker.patch > Add Freemarker Scripting Support > > > Key: SLING-87 > URL: https://issues.apache.org/jira/browse/SLING-87 > Project: Sling > Issue Type: New Feature > Components: microsling >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: freemarker.patch > > > Add freemarker scripting support to microsling using the scriptengine > interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-87) Add Freemarker Scripting Support
[ https://issues.apache.org/jira/browse/SLING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-87: Attachment: (was: freemarker.patch) > Add Freemarker Scripting Support > > > Key: SLING-87 > URL: https://issues.apache.org/jira/browse/SLING-87 > Project: Sling > Issue Type: New Feature > Components: microsling >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: freemarker.patch > > > Add freemarker scripting support to microsling using the scriptengine > interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-87) Add Freemarker Scripting Support
[ https://issues.apache.org/jira/browse/SLING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-87: Attachment: freemarker.patch This patch is a simple freemarker script engine. > Add Freemarker Scripting Support > > > Key: SLING-87 > URL: https://issues.apache.org/jira/browse/SLING-87 > Project: Sling > Issue Type: New Feature > Components: microsling >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: freemarker.patch > > > Add freemarker scripting support to microsling using the scriptengine > interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-87) Add Freemarker Scripting Support
Add Freemarker Scripting Support Key: SLING-87 URL: https://issues.apache.org/jira/browse/SLING-87 Project: Sling Issue Type: New Feature Components: microsling Affects Versions: 2.0.0 Reporter: Padraic Hannon Add freemarker scripting support to microsling using the scriptengine interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-86) Support for jcr namespace prefixes
[ https://issues.apache.org/jira/browse/SLING-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-86. - Resolution: Fixed > Support for jcr namespace prefixes > -- > > Key: SLING-86 > URL: https://issues.apache.org/jira/browse/SLING-86 > Project: Sling > Issue Type: New Feature > Components: Content >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > Namespace handling with jcr can become complicated as usually the application > is just using prefixes instead of the full namespace uri. Therefore the > application either has to make assumptions about the registered prefixes or > has to lookup the used prefixes. While the assumptions obviously can lead to > problems, the second solution is very hard and time consuming to implement. > Sling can help in this respect as it ensures that some prefixes point to the > correct namespace regardless of how they are registered in the repository. > This can be done by reassigning namespaces on a per session base. > The idea is that a bundle can have the "Sling-Namespaces" manifest entry > which can contain one or more definition for namespaces, like > Sling-Namespaces: sling=http://sling.apache.org/jcr/core/1.0 > Sling will take care that these prefixes are mapped accordingly for each > session which is get through Sling. There an application based on Sling can > safely make the assumption about these namespace prefixes. > The manifest entries will be read on a bundle install event and updated on an > uninstall event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[api] Added RequestDispatcherOptions
I have added a RequestDispatcherOptions class (really just a Map, with some constants for well-known options names) to these methods: 1) in SlingHttpServletRequest: RequestDispatcher getRequestDispatcher(Resource resource, RequestDispatcherOptions options) 2) in SlingScriptHelper void include(String path,RequestDispatcherOptions options) Here's from the javadocs of RequestDispatcherOptions: * Typical use cases include: * * * Forcing a resource type, to render a Resource in a specific way, * like for example render myself in a suitable way for a navigation box. * * * Adding selectors when including a Resource, like for example add * a "teaser" selector to the request that I'm including here. * * Comments are welcome, -Bertrand
Re: Sling-API
On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > ...Yes I guess the terminology is a bit confusing. A Resource is also > something used in WebDAV. But I guess the naming issue is done and > dusted already Yes, obviously Resource can mean different things, but in our quest to expose the REST style it seems to be the best name. We can always talk about a "Sling Resource" if we need to qualify it. > ...This is fine for new implementation. What if one need to implement > legacy services, where the url patterns used are different? > > Providing the request selector as the default mechanism is good. > Having it as the only mechanism is bad Agreed. Although microsling is not meant to be "user-extensible", it is sufficiently simple (and will be even smaller once it uses the sling-api that we're discussing here) that one can replace any part of it easily by extending classes. And in Sling OSGi, I guess pretty much everything can be replaced by way of OSGi bundles. > ...My preference would be to have > only one sling, where OSGi is optional though Considering the discussions in the last few weeks, it seems like we're headed for a lightweight microsling, meant mostly as an educational/demo tool but also usable for simple applications, and the full-blown Sling, based on OSGi, extensible, etc. Both are based on the same API, and the microsling code will be very small, so I think that's a good approach. But, depending on how people use microsling and Sling, we might migrate software components "down" or "up" until we find the right balance. -Bertrand
Re: Sling-API
On 29 Oct 2007, at 14:54, Bertrand Delacretaz wrote: Hi Torgeir, On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: ...2. Generalise the "Servlet" into a sort of "View" component. The best analogy is probably Struts' ActionForward class ...My main concern is that I'm interested in seeing model resolution and view resolution separated. I guess with the current framework, model resolution is opaque to Sling, and the Resource component represents the "view" Not sure what you mean by "Resource component". In microsling (which drives the Sling API redesign), Components are gone, there's only -The Resource, which represents, in its simplest form, a JCR Node -The Servlet (or script) which handles the request So, although MVC does not really apply here, If we want to think in MVC terms I'd say the Resource is the Model, and the Servlet is the view (in the case of a GET method), or the controller (in the case of a POST/PUT/DELETE/unsafe) method. If we follow this reasoning, you'd handle a POST request by having microsling call a first "controller" script that manipulates data, and forwards to a GET request which calls the "view" script. Does that make sense to you? I think working in this way might help people embrace the REST style, which is IMHO a nice side effect. Yes I guess the terminology is a bit confusing. A Resource is also something used in WebDAV. But I guess the naming issue is done and dusted already. ...A better example than in my previous message is a blog. Ideally, the model for the blog would be loaded first. Then, depending on the view being RSS or normal HTML view, a view resolver would direct to the correct Servlet. With the current framework, a single component would be needed for both RSS and normal view?... If by component you mean a microsling Servlet/Script, then the answer is no: the request selectors (.rss.xml) or extension (.rss) will cause a different rendering script to be used. This is fine for new implementation. What if one need to implement legacy services, where the url patterns used are different? Providing the request selector as the default mechanism is good. Having it as the only mechanism is bad. 3. Extend the MicroslingRequestContext implementation to resolve a number of ResourceResolver and ServletResolver from the service locator ...The reason for this is to facilitate overriding the default resolver. How would you do that in a situation where you need only a few special cases, but otherwise the default behaviour?... I think we all agree on that for Sling, but do we want this in microsling, and if yes how do we implement that cleanly? The easiest thing that comes to mind is a composite pattern: as seen from the API, there's only one ResourceResolver, but internally that ResourceResolver can use a chain of ResourceResolvers. Ok, Felix also stated this clearly. My preference would be to have only one sling, where OSGi is optional though. -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Assigned: (SLING-86) Support for jcr namespace prefixes
[ https://issues.apache.org/jira/browse/SLING-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-86: - Assignee: Carsten Ziegeler > Support for jcr namespace prefixes > -- > > Key: SLING-86 > URL: https://issues.apache.org/jira/browse/SLING-86 > Project: Sling > Issue Type: New Feature > Components: Content >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > > Namespace handling with jcr can become complicated as usually the application > is just using prefixes instead of the full namespace uri. Therefore the > application either has to make assumptions about the registered prefixes or > has to lookup the used prefixes. While the assumptions obviously can lead to > problems, the second solution is very hard and time consuming to implement. > Sling can help in this respect as it ensures that some prefixes point to the > correct namespace regardless of how they are registered in the repository. > This can be done by reassigning namespaces on a per session base. > The idea is that a bundle can have the "Sling-Namespaces" manifest entry > which can contain one or more definition for namespaces, like > Sling-Namespaces: sling=http://sling.apache.org/jcr/core/1.0 > Sling will take care that these prefixes are mapped accordingly for each > session which is get through Sling. There an application based on Sling can > safely make the assumption about these namespace prefixes. > The manifest entries will be read on a bundle install event and updated on an > uninstall event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling-API
Hi Torgeir, On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > >> ...2. Generalise the "Servlet" into a sort of "View" component. The best > >> analogy is probably Struts' ActionForward class > ...My main concern is that I'm interested in seeing model resolution and > view resolution separated. I guess with the current framework, model > resolution is opaque to Sling, and the Resource component represents > the "view" Not sure what you mean by "Resource component". In microsling (which drives the Sling API redesign), Components are gone, there's only -The Resource, which represents, in its simplest form, a JCR Node -The Servlet (or script) which handles the request So, although MVC does not really apply here, If we want to think in MVC terms I'd say the Resource is the Model, and the Servlet is the view (in the case of a GET method), or the controller (in the case of a POST/PUT/DELETE/unsafe) method. If we follow this reasoning, you'd handle a POST request by having microsling call a first "controller" script that manipulates data, and forwards to a GET request which calls the "view" script. Does that make sense to you? I think working in this way might help people embrace the REST style, which is IMHO a nice side effect. > ...A better example than in my previous message is a blog. Ideally, the > model for the blog would be loaded first. Then, depending on the view > being RSS or normal HTML view, a view resolver would direct to the > correct Servlet. With the current framework, a single component would > be needed for both RSS and normal view?... If by component you mean a microsling Servlet/Script, then the answer is no: the request selectors (.rss.xml) or extension (.rss) will cause a different rendering script to be used. > >> 3. Extend the MicroslingRequestContext implementation to resolve a > >> number of ResourceResolver and ServletResolver from the service > >> locator > ...The reason for this is to facilitate overriding the default resolver. > How would you do that in a situation where you need only a few > special cases, but otherwise the default behaviour?... I think we all agree on that for Sling, but do we want this in microsling, and if yes how do we implement that cleanly? The easiest thing that comes to mind is a composite pattern: as seen from the API, there's only one ResourceResolver, but internally that ResourceResolver can use a chain of ResourceResolvers. -Bertrand
Re: [RT] ScriptResolver
hi lars, thanks a lot for the illustration. i think this is a great approach. i would like to ask a couple of detailed questions though. > If two nodes in the graph have the same distance to the primaryType, > following rules are applied: > 1) nt:base has precedence over nt:unstructured really? my gut feel would have been the other way around... i haven't thought it through though... did you have a particular rationale that you can share? > 2) built-in node types have precedence over nt:base since nt:base is the "mother" all built-in nodes i think i can agree to the sentence pre-pending "other " ;) > 3) user-defined node types have precedence over built-in node types ack. > 4) an alphabetical precedence ordering takes place it sounds like this is so arbitrary that i would probably just opt for a quick "implementation" defined (==undefined) resolution instead of sorting. what do you think? did you mean to specify a resolution order by (1) - (4) or is the sequence of the rules arbitrary. regards, david
[jira] Created: (SLING-86) Support for jcr namespace prefixes
Support for jcr namespace prefixes -- Key: SLING-86 URL: https://issues.apache.org/jira/browse/SLING-86 Project: Sling Issue Type: New Feature Components: Content Reporter: Carsten Ziegeler Namespace handling with jcr can become complicated as usually the application is just using prefixes instead of the full namespace uri. Therefore the application either has to make assumptions about the registered prefixes or has to lookup the used prefixes. While the assumptions obviously can lead to problems, the second solution is very hard and time consuming to implement. Sling can help in this respect as it ensures that some prefixes point to the correct namespace regardless of how they are registered in the repository. This can be done by reassigning namespaces on a per session base. The idea is that a bundle can have the "Sling-Namespaces" manifest entry which can contain one or more definition for namespaces, like Sling-Namespaces: sling=http://sling.apache.org/jcr/core/1.0 Sling will take care that these prefixes are mapped accordingly for each session which is get through Sling. There an application based on Sling can safely make the assumption about these namespace prefixes. The manifest entries will be read on a bundle install event and updated on an uninstall event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling-API
On 27 Oct 2007, at 16:42, Felix Meschberger wrote: Hi, Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: Some suggestions: 2. Generalise the "Servlet" into a sort of "View" component. The best analogy is probably Struts' ActionForward class. Wouldn't it be appropriate to use a JSP as a view component for a Resource? I feel that having the SlingMainServlet resolve to view components is duplicating functionality available in the servlet container. A SlingForward could either be initialised with a resource type, requesting handling by the appropriate SlingServlet for the resource type, by a normal path parameter to forward to a JSP decided by the servlet container, or some other constant to request handling by a script execution servlet. The above interface would then contain the method This is too much overhead and in fact is one of the main concerns I have with Struts. I think the current solution of resolving the request to a Servlet (taking the Resource and other request properties (method, selectors, extension) into account is appropriate. If the response should be rendered by another Servlet (be it a normal servlet, be it a script, or whatever) may be implemented by standard request forwarding. My main concern is that I'm interested in seeing model resolution and view resolution separated. I guess with the current framework, model resolution is opaque to Sling, and the Resource component represents the "view". A better example than in my previous message is a blog. Ideally, the model for the blog would be loaded first. Then, depending on the view being RSS or normal HTML view, a view resolver would direct to the correct Servlet. With the current framework, a single component would be needed for both RSS and normal view? 3. Extend the MicroslingRequestContext implementation to resolve a number of ResourceResolver and ServletResolver from the service locator. They should be orderly configured, and each one tried until one actually resolves a Resource / Servlet. This would be needed for the suggested ServletResolver setup to be easily extended as suggested above. I do not think, that this is appropriate for microsling. For the real Sling we might implement such feature of chained Resource- and ServletResolvers as actual requirements would raise. On the API level, I would not codify this. The reason for this is to facilitate overriding the default resolver. How would you do that in a situation where you need only a few special cases, but otherwise the default behaviour? My preference for such cases would be to have it in the API, since it would otherwise require using implementation specific coding. -- Torgeir Veimo [EMAIL PROTECTED]
Re: Paper submission for ApacheCon EU 2008
Hi Bertrand, Am 26.10.2007 um 14:31 schrieb Bertrand Delacretaz: On 10/26/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: ...I have right now submitted a proposal for an talk on architectures for content-centric web applications,.. Ours is bare-metal pragmatic stuff, as I understand you have a more theoretical/architectural view, so the talks would probably complement each other nicely! You are right, I am coming from a very abstract view of user-content interaction to an idealistic view of a web framework for content centric applications. And this idealistic view meets in the end the reality of microsling. Lars
Re: [RT] ScriptResolver
Hi Felix, What I would like to work out is how an intelligent script resolution could work that allows multiple levels of fallbacks and that supports mixin types. Cool, would be very interested in such an approach. Out of my head, here is how I would do it (for an illustration, see http://weblogs.goshaky.com/weblogs/lars/resource/scriptresolution.png) : For script resolution, we create a weighted list of candidate paths. As soon as a script is found in a candidate path, we start looking for refinements, or mixin-specific scripts. The first candidate is the path denoted by slingResouceType. If this is not set, we resort to the primaryNode type. If there is no script available, we build a graph of declaredSuperTypes and use the first matching script. If two nodes in the graph have the same distance to the primaryType, following rules are applied: 1) nt:base has precedence over nt:unstructured 2) built-in node types have precedence over nt:base 3) user-defined node types have precedence over built-in node types 4) an alphabetical precedence ordering takes place In the case of a defined slingResourceType, we deal with mixins in the following way: if there are sub-folders in the folder denoted by the slingResourceType that have a naming pattern that matches the declared mixin types, descend into these folders and try to find a script. A deeper descend beats a more shallow descend, so for instance /mix/referenceable/mix/versionable beats /mix/referenceable if two scripts are found at the same level, the precedence rules expressed above take place, so that /mix/versionable/mix/userdefined beats /mix/referenceable/mix/ versionable because of rule 3) regards, Lars
[api] Why do SlingHttpServlet*Wrappers wrap Sling objects, not javax.Servlet ones?
Hi, Looking at the current sling-api: public SlingHttpServletRequestWrapper(SlingHttpServletRequest delegatee) I would have expected public SlingHttpServletRequestWrapper(ServletRequest delegatee) And then the constructor can complain if the delegatee (why not call that simply "wrappedRequest" by the way?) is not of the right type. And the same goes for the response wrapper, of course. What's the rationale for doing things the current way? I'm not against that, just trying to understand the pros and cons. -Bertrand
Re: Sling-API
On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: > >... 2. Generalise the "Servlet" into a sort of "View" component. The best > > analogy is probably Struts' ActionForward class... > ...This is too much overhead and in fact is one of the main concerns I have > with Struts. ... > ...If the response > should be rendered by another Servlet (be it a normal servlet, be it a > script, or whatever) may be implemented by standard request forwarding... I see your point, but I have also this vague feeling that microsling and the Sling API could better separate (or maybe just better expose) the "processing" and "rendering" phases of a request. Felix, how would you suggest implementing a POST script that renders data when done processing? Do a request forwarding at the end of the POST script? That might be ok, but the programmer might want to specify exactly which rendering script they want to use after the POST, so some short-circuit of the standard Resource/SlingScript resolution might be needed. WDYT? > >... 3. Extend the MicroslingRequestContext implementation to resolve a > > number of ResourceResolver and ServletResolver from the service > > locator... > I do not think, that this is appropriate for microsling... Dunno...Torgeir, if you need this in microsling, and if you can provide simple code to implement it, I'd be +1 on putting this in microsling. But I agree with Felix that not having this in microsling still allows Sling to have that, based on OSGi "plugins".. -Bertrand
Re: Sling-API
Hi, Thanks Felix for the API changes - the packages structure looks very understandable to me now, I think that's a great step in making Sling easy to understand. On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Bertrand: > > ...7) SlingScriptEngine > > > > Should we have two eval() methods? > > > > eval(script, props, request, response) for servlet environments > > > > eval(script, props, reader, writer) for "internal" scripts > > I think eval(Script, Map) suffices it and should > encompass enough information needed You're right, but coming back to my original motivation for the second eval() above, I think scripts need access to the logging framework. Should be add a "log" variable to the standard scripting variables defined by SlingScriptEngine? > >... 9) Constants > > ... > > I'd also move that class to the "helpers" package - it is not > > interesting to study. > > I do not actually agree. But it is just sort of a guts feeling :-)... Ok to keep Constants right under the api package. > >... 10) SlingHttpServlet... > > I'd move these classes to the "servlets" package, and maybe move the > > SlingXMethodsServlets to servlets/helpers - that's what they are I > > think, and that would prevent the package from having too much stuff. > > I do not agree as the SlingHttpServletRequest/Response interfaces are > two of the central interfaces of interest to Sling programmers: These > are the first interfaces they are confronted with, so I would rather > keep them upfront Ok about them being important, but are they *so* important as to be right in the api package? Why can't we move them to their respective "request" and "response" packages? > > ...12) javadocs > > In general I find the javadoc comments too verbose for my taste > Well, I disagree :-) The API speficies a central part of Sling and as > such should be specific as much as possible to not run the danger of > being underspecified and thus create problems in the future, where > people might expect something, which does not match the implementation I did not mean to remove any information from the javadocs, just write things in a terser way. But this is not critical to getting the API right, so I'd suggest keeping this javadocs discussion for later. -Bertrand
