[jira] Updated: (SLING-90) Add support for creating Ruby templates
[ https://issues.apache.org/jira/browse/SLING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShawnAnderson updated SLING-90: --- Attachment: ruby.patch updated for microsling-core repos location > Add support for creating Ruby templates > --- > > Key: SLING-90 > URL: https://issues.apache.org/jira/browse/SLING-90 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Padraic Hannon > Attachments: ruby.patch, ruby.patch > > > By adding support for ruby scripted templates microsling could deal with > adding dynamic mixins, which is something that java has a hard time with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-90) Add support for creating Ruby templates
[ https://issues.apache.org/jira/browse/SLING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShawnAnderson updated SLING-90: --- Attachment: ruby.patch added ruby support to microsling in the whiteboard repository. > Add support for creating Ruby templates > --- > > Key: SLING-90 > URL: https://issues.apache.org/jira/browse/SLING-90 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Padraic Hannon > Attachments: ruby.patch > > > By adding support for ruby scripted templates microsling could deal with > adding dynamic mixins, which is something that java has a hard time with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-88) Use the sling-api from SLING-28 in microsling
[ https://issues.apache.org/jira/browse/SLING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz reassigned SLING-88: Assignee: (was: Bertrand Delacretaz) > Use the sling-api from SLING-28 in microsling > - > > Key: SLING-88 > URL: https://issues.apache.org/jira/browse/SLING-88 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz > > Once we agree on SLING-28, microsling can be "ported" to this API, so that > both microsling and Sling use it. > Make sure to tag > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling/ before > doing 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-88) Use the sling-api from SLING-28 in microsling
[ https://issues.apache.org/jira/browse/SLING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539415 ] Bertrand Delacretaz commented on SLING-88: -- In revision 591050, all "mvn install" tests (= 49 unit + 24 integration tests) pass on my macosx system. I quickly tried on a linux box and some integration tests failed, haven't had time to investigate. > Use the sling-api from SLING-28 in microsling > - > > Key: SLING-88 > URL: https://issues.apache.org/jira/browse/SLING-88 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > Once we agree on SLING-28, microsling can be "ported" to this API, so that > both microsling and Sling use it. > Make sure to tag > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling/ before > doing this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling API: Hanlding non-existing resources in ResourceResolver
Sounds good to me, I never like throwing an exception if something cannot be found, as that seems to be a normal state when looking things up. -paddy On Nov 1, 2007, at 5:53 AM, Carsten Ziegeler wrote: Felix Meschberger wrote: Hi all, Currently the ResourceResolver.resolve(ServletRequest request) method throws a ResourceNotFoundException if the request cannot be resolved to a resource. This makes it virtually impossible to easily and transparently handle requests for resource creation. This in fact is also an overseen difference between microsling and Sling: microsling is built around accepting missing resources while Sling throws 404 unconditionally if a request cannot be resolved to a resource. This prevents applications trying to create resources. As a fix I propose the introduction of a new special resource type "sling:nonexisting", which is to be used by the ResourceResolver.resolve method to create a pseudo-Resource from the request path (rawData and object are both null). This may then be used to create the resource, such as in the DefaultSlingServlet. (The nice thing about the sling:nonexisting resource type is, that of course scripts may be created to handle respective methods for these types). Consquences in the API: The methods of the ResourceResolver and ResourceManager interfaces throwing a ResourceNotFoundException are modified to return null if a Resource cannot be found (except the resolve method which always returns a Resource instance, with the sling:nonexisting resource type in the case of nonexisting resources). And of course the ResourceNodeFoundException is dropped as it is not needed any more. I will modify the API to reflect this proposal. WDYT ? +1 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-91) MicroslingRequestPathInfo does not decompose paths correctly
[ https://issues.apache.org/jira/browse/SLING-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-91. -- Resolution: Fixed This has been fixed as part of the "big" refactoring of microsling. > MicroslingRequestPathInfo does not decompose paths correctly > > > Key: SLING-91 > URL: https://issues.apache.org/jira/browse/SLING-91 > Project: Sling > Issue Type: Bug > Components: microsling >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Given a request URI of "/a/b/c.sep.html/suffix" and a resolved Resource at > "/a", the selectors and extension are empty and the suffix is > "/b/c.sep.html/suffix". The current implementation returns "sep" as the > separator string, "html" as the extension and "/suffix" as the suffix. The > remaining part of the path - "/b/c" is returned as "unused content path". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-88) Use the sling-api from SLING-28 in microsling
[ https://issues.apache.org/jira/browse/SLING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539371 ] Bertrand Delacretaz commented on SLING-88: -- Felix has committed an intial version under http://svn.apache.org/repos/asf/incubator/sling/trunk/microsling/microsling-core/, I'll work on the test cases that currently fail. > Use the sling-api from SLING-28 in microsling > - > > Key: SLING-88 > URL: https://issues.apache.org/jira/browse/SLING-88 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > Once we agree on SLING-28, microsling can be "ported" to this API, so that > both microsling and Sling use it. > Make sure to tag > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling/ before > doing this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-88) Use the sling-api from SLING-28 in microsling
[ https://issues.apache.org/jira/browse/SLING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz reassigned SLING-88: Assignee: Bertrand Delacretaz > Use the sling-api from SLING-28 in microsling > - > > Key: SLING-88 > URL: https://issues.apache.org/jira/browse/SLING-88 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > Once we agree on SLING-28, microsling can be "ported" to this API, so that > both microsling and Sling use it. > Make sure to tag > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling/ before > doing this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
microsling changes
Hi all, As the Sling API is now being settled on, I have adapted microsling to the Sling API and at the same time copied it over to the trunk under microsling/microsling-core. Expect microsling to contain some bugs from the migration. I am currently working on resolving them. We will keep the "old" microsling in the whiteboard for now. Later in time we will tag and remove the microsling from the whiteboard. But work has actually stopped in the whiteboard and will only continue in the trunk. Regards Felix
Re: Sling API: Hanlding non-existing resources in ResourceResolver
On 11/1/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...As a fix I propose the introduction of a new special resource type > "sling:nonexisting", which is to be used by the ResourceResolver.resolve > method to create a pseudo-Resource from the request path (rawData and > object are both null) Ok, and I'd make this pseudo resource an API class. Having a NonExistingResource class with resourceType=sling:nonexisting might make things clearer, and exposing this class in the API makes the mechanism more obvious. > ...I will modify the API to reflect this proposal... +1 -Bertrand
[jira] Assigned: (SLING-92) microjax - lightweight Ajax client and servlet for microsling
[ https://issues.apache.org/jira/browse/SLING-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz reassigned SLING-92: Assignee: Bertrand Delacretaz > microjax - lightweight Ajax client and servlet for microsling > - > > Key: SLING-92 > URL: https://issues.apache.org/jira/browse/SLING-92 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > > As discussed on the mailing list [1], I'll contribute to microsling the > experimental "r-jax" stuff [2] that we wrote together with David Nuescheler. > The main changes are: > 1) The default microsling servlet needs to handle POSTs in a more clever way, > to provide useful services to the javascript client > 2) For GETs, the default microsling servlet needs to provide a JSON > representation, when the json extension is used. This will be extensible to > XML and other output formats. > [1] http://thread.gmane.org/gmane.comp.apache.sling.devel/721 > [2] http://www.day.com/maven/rjax/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New Sling JSON module
On 11/1/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ...in order to avoid all those private copies of the json.org classes in > various modules (and own projects), I moved the json classes to an own > bundles which is now referenced from the others Great - I'll need that Real Soon Now for SLING-92. -Bertrand
[jira] Updated: (SLING-92) microjax - lightweight Ajax client and servlet for microsling
[ https://issues.apache.org/jira/browse/SLING-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-92: - Component/s: microsling > microjax - lightweight Ajax client and servlet for microsling > - > > Key: SLING-92 > URL: https://issues.apache.org/jira/browse/SLING-92 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Priority: Minor > > As discussed on the mailing list [1], I'll contribute to microsling the > experimental "r-jax" stuff [2] that we wrote together with David Nuescheler. > The main changes are: > 1) The default microsling servlet needs to handle POSTs in a more clever way, > to provide useful services to the javascript client > 2) For GETs, the default microsling servlet needs to provide a JSON > representation, when the json extension is used. This will be extensible to > XML and other output formats. > [1] http://thread.gmane.org/gmane.comp.apache.sling.devel/721 > [2] http://www.day.com/maven/rjax/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling API: Hanlding non-existing resources in ResourceResolver
Felix Meschberger wrote: > Hi all, > > Currently the ResourceResolver.resolve(ServletRequest request) method > throws a ResourceNotFoundException if the request cannot be resolved to > a resource. This makes it virtually impossible to easily and > transparently handle requests for resource creation. > > This in fact is also an overseen difference between microsling and > Sling: microsling is built around accepting missing resources while > Sling throws 404 unconditionally if a request cannot be resolved to a > resource. This prevents applications trying to create resources. > > As a fix I propose the introduction of a new special resource type > "sling:nonexisting", which is to be used by the ResourceResolver.resolve > method to create a pseudo-Resource from the request path (rawData and > object are both null). This may then be used to create the resource, > such as in the DefaultSlingServlet. (The nice thing about the > sling:nonexisting resource type is, that of course scripts may be > created to handle respective methods for these types). > > Consquences in the API: The methods of the ResourceResolver and > ResourceManager interfaces throwing a ResourceNotFoundException are > modified to return null if a Resource cannot be found (except the > resolve method which always returns a Resource instance, with the > sling:nonexisting resource type in the case of nonexisting resources). > And of course the ResourceNodeFoundException is dropped as it is not > needed any more. > > I will modify the API to reflect this proposal. > > WDYT ? > +1 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
New Sling JSON module
Hi, in order to avoid all those private copies of the json.org classes in various modules (and own projects), I moved the json classes to an own bundles which is now referenced from the others. This gives us the chance to add all json related stuff to this module as well. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [RT] microsling ajax client
On 11/1/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: > ...I know how much we all value these discussions, but as RJAX is taken > and a really bad acronym and microajax is already taken by another > framework, what about using > > AJACs - Asynchronous Javascript and Content don't like that, the sounds is the same as the real Ajax. Note that my proposal was not microajax, it was microjax, which does not seem to be used by other software. -Bertrand
Re: [RT] microsling ajax client
> > We could use microjax as a nickname maybe. how about "slingjax". regards, david
Re: [RT] microsling ajax client
I know how much we all value these discussions, but as RJAX is taken and a really bad acronym and microajax is already taken by another framework, what about using AJACs - Asynchronous Javascript and Content. The trailing S stands for Sling (of couse) and it makes the word almost sound like AJAX. Lars Am 01.11.2007 um 09:55 schrieb Bertrand Delacretaz: On 11/1/07, Michael Marth <[EMAIL PROTECTED]> wrote: One comment: if we package "microsling Ajax client" (can we find another name, please?) ... no, no, not names again...arrg..please... ;-) We could use microjax as a nickname maybe. -- Lars Trieloff [EMAIL PROTECTED] http://weblogs.goshaky.com/weblogs/lars
Re: [RT] microsling ajax client
Is there a client-side ESP implementation? This would make it even cooler: Using Javascript client-side and server-side, with ESP as templating mechanism and the same JSON-to-JCR-mapping in both tiers can speed up training and development dramatically. Lars Am 01.11.2007 um 09:48 schrieb Michael Marth: Nice idea. One comment: if we package "microsling Ajax client" (can we find another name, please?) with microsling it makes even more sense to have esp as the default scripting language (the app developer needs to think in only one language - be it on the server or on the client) -- Lars Trieloff [EMAIL PROTECTED] http://weblogs.goshaky.com/weblogs/lars
Sling API: Hanlding non-existing resources in ResourceResolver
Hi all, Currently the ResourceResolver.resolve(ServletRequest request) method throws a ResourceNotFoundException if the request cannot be resolved to a resource. This makes it virtually impossible to easily and transparently handle requests for resource creation. This in fact is also an overseen difference between microsling and Sling: microsling is built around accepting missing resources while Sling throws 404 unconditionally if a request cannot be resolved to a resource. This prevents applications trying to create resources. As a fix I propose the introduction of a new special resource type "sling:nonexisting", which is to be used by the ResourceResolver.resolve method to create a pseudo-Resource from the request path (rawData and object are both null). This may then be used to create the resource, such as in the DefaultSlingServlet. (The nice thing about the sling:nonexisting resource type is, that of course scripts may be created to handle respective methods for these types). Consquences in the API: The methods of the ResourceResolver and ResourceManager interfaces throwing a ResourceNotFoundException are modified to return null if a Resource cannot be found (except the resolve method which always returns a Resource instance, with the sling:nonexisting resource type in the case of nonexisting resources). And of course the ResourceNodeFoundException is dropped as it is not needed any more. I will modify the API to reflect this proposal. WDYT ? Regards Felix
[jira] Created: (SLING-92) microjax - lightweight Ajax client and servlet for microsling
microjax - lightweight Ajax client and servlet for microsling - Key: SLING-92 URL: https://issues.apache.org/jira/browse/SLING-92 Project: Sling Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor As discussed on the mailing list [1], I'll contribute to microsling the experimental "r-jax" stuff [2] that we wrote together with David Nuescheler. The main changes are: 1) The default microsling servlet needs to handle POSTs in a more clever way, to provide useful services to the javascript client 2) For GETs, the default microsling servlet needs to provide a JSON representation, when the json extension is used. This will be extensible to XML and other output formats. [1] http://thread.gmane.org/gmane.comp.apache.sling.devel/721 [2] http://www.day.com/maven/rjax/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] microsling ajax client
On 10/31/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > 2) Enhancing the DefaultSlingServlet's doGet method to return Items in > > JSON format by default > ...What about adding this as a default handler for the json extension, > compared to an XML serialization as a default handler for the xml > extension You're right, makes much more sense; for the GET method, have the DefaultSlingServlet delegate to default renderers for json, xml, txt, ... >... (I am still thinking about adding a certain XML-processing > framework as a very powerful script engine to Sling)... So am I, and it's probably the same framework ;-) > ...We should make sure we use the same JCR-JSON-mapping for RJAX and the > Rhino HostObjects used on the server Right, I'll probably start by contributing our prototype as is, and we can refine it so that both "APIs" match. > ...I think we should spend some time thinking about integrating this Web > Forms 2.0 http://www.whatwg.org/specs/web-forms/current-work/ ... I'm not familiar with that spec, what does that imply, broadly speaking? -Bertrand
Re: [RT] microsling ajax client
On 11/1/07, Michael Marth <[EMAIL PROTECTED]> wrote: > One comment: if we package "microsling Ajax client" (can we find another > name, please?) ... no, no, not names again...arrg..please... ;-) We could use microjax as a nickname maybe. > ...with microsling it makes even more sense to have esp as the > default scripting language (the app developer needs to think in only one > language - be it on the server or on the client)... Sure, having javascript on both ends is cool. -Bertrand
Re: [RT] microsling ajax client
Nice idea. One comment: if we package "microsling Ajax client" (can we find another name, please?) with microsling it makes even more sense to have esp as the default scripting language (the app developer needs to think in only one language - be it on the server or on the client) Michael On 11/1/07, Christophe Lombart <[EMAIL PROTECTED]> wrote: > > +1. Great idea. > > On 10/31/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > > > > > What about adding this as a default handler for the json extension, > > compared to an XML serialization as a default handler for the xml > > extension. (I am still thinking about adding a certain XML-processing > > framework as a very powerful script engine to Sling) > > > or use the current behaviour for a "debug" extension. > > Christophe >
Re: [RT] microsling ajax client
+1. Great idea. On 10/31/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > > What about adding this as a default handler for the json extension, > compared to an XML serialization as a default handler for the xml > extension. (I am still thinking about adding a certain XML-processing > framework as a very powerful script engine to Sling) or use the current behaviour for a "debug" extension. Christophe
