[jira] Resolved: (SLING-307) JsonQueryServlet
[
https://issues.apache.org/jira/browse/SLING-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved SLING-307.
-
Resolution: Fixed
Fix Version/s: 2.0.0
After adapting the JsonQueryServlet to the Resource paradigm in Rev. 636656 I
think this issue can be resolved.
And of course the integration tests still succeed ;-)
Please close if it works ok for you. Thanks.
> JsonQueryServlet
>
>
> Key: SLING-307
> URL: https://issues.apache.org/jira/browse/SLING-307
> Project: Sling
> Issue Type: New Feature
> Components: Default Servlets
>Reporter: Philipp Koch
>Assignee: Bertrand Delacretaz
> Fix For: 2.0.0
>
> Attachments: queryservlet.patch
>
>
> it would be nice to have a way to specify a jcr query in the url in order to
> query the underlying jcr repository.
> the attached patch works as follows:
> The new query servlet is called if the extension is ".json" and the selector
> is set to "query". you can pass following parameters in the url:
> statement: jcr query statement (XPATH or SQL)
> queryType: xpath or sql (of none is specified xpath is taken)
> property: specifies which property (relative path) has to be "put" into the
> result set (this parameter can be added multiple times)
> excerptPath: specifies the relative node path from where the excerpt has to
> be built.
> the result is returned as json string. e.g.:
> [
> {"name":"ee0","rep:excerpt()":"geometrixx/components/contentpage
> ...
> ee<\/fragment><\/excerpt>","jcr:path":"/content/ee0","jcr:score":"528","cq:content/jcr:title":"ee"},
> {"name":"news","rep:excerpt()":" ...
> geometrixx/components/contentpage ... ... ... ... news about
> geometrix<\/fragment><\/excerpt>","jcr:path":"/content/geometrixx/en/about/news","jcr:score":"521","cq:content/jcr:title":"News"}
> ]
> example query call:
> http://localhost:8080/sling/myhome.query.json?statement=//element(*,cq:Page)[jcr:contains(.,'sling')]/(rep:excerpt(.))&property=cq:content/jcr:title&excerptPath=cq:content
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Heading a first Releas: Part I SNAPSHOT Dependencies
Felix Meschberger wrote: Hi all, I am trying to head at a first Sling release now, so I am starting to look at our dependencies to ensure, we don't have any external SNAPSHOT dependencies. In a second mail, I will wrap up JIRA issues which are currently still open to select the issues, we deem required to be fixed before a release. First let's see the SNAPSHOT dependencies: org.apache.felix:maven-scr-plugin:1.0.4-SNAPSHOT - vote for 1.0.4 release under way, so this will be resolved shortly org.apache.felix.commons:org.apache.felix.commons.commons-collections:3.2.0-0001-SNAPSHOT - Unreleased wrapping provided by Apache Felix org.apache.jackrabbit:jackrabbit-jcr-rmi:1.5-SNAPSHOT - Required for fixes to JCR-1406 and JCR-1454 - I will try to get a 1.4.1 release with backported fixes org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT - library is itself an OSGi Bundle - I will try to get a 1.4.1 release with backported fix Unless I missed a dependency, we are very close to be SNAPSHOT dependency free. I will try to get the above mentioned releases from the Jackrabbit project. Carsten, do you know anything about the an imminent release of the Jakarta Commons Collections library as an OSGi bundle ? Yes or .. no :) There is a release of lang upcomming in the near future, but a new release of collections is not visible atm. Am I missing something ? What about the ujax renaming David suggested recently? I think this is something we should do before a first release. (it shouldn't be that hard). The scheduler bundle requires commons beanutils and digester (and perhaps one more). I'm planning to include these into the bundle today. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Closed: (SLING-259) Bundle based Resource should be able to adapt to Repository Item
[ https://issues.apache.org/jira/browse/SLING-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-259. --- Resolution: Fixed Fixed as indicated in previous comments in Rev. 636658. Now a BundleResource is only created, if ... * the path addresses an existing Bundle resource file or * the path addresses an existing Bundle resource folder and no repository item of the same name exists Otherwise, particularly in case of a Bundle resource folder hiding an existing repository item, no BundleResource is returned. > Bundle based Resource should be able to adapt to Repository Item > > > Key: SLING-259 > URL: https://issues.apache.org/jira/browse/SLING-259 > Project: Sling > Issue Type: Improvement > Components: Resource >Reporter: Dominique Jäggi >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When using bundle based Resources, items stored in the repository may be > hidden by the actual bundle resources. This is ok for file-like resources but > might be problematic in some situations for folders. > It would probably be helpfull, if bundle based resources would be able to > adapt to repository items if an item would exist at the path of the resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-259) Bundle based Resource should be able to adapt to Repository Item
[ https://issues.apache.org/jira/browse/SLING-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578173#action_12578173 ] fmeschbe edited comment on SLING-259 at 3/13/08 12:46 AM: --- Fixed as indicated in previous comments in Rev. 636658. Now a BundleResource is only created, if ... * the path addresses an existing Bundle resource file or * the path addresses an existing Bundle resource folder and no repository item of the same name exists Otherwise, particularly in case of a Bundle resource folder hiding an existing repository item, no BundleResource is returned. As a consequence BundleResource instances do not adapt to repository items any more. This would just be very confusing as one resource might have two different contents (as per InputStream) and URLs. was (Author: fmeschbe): Fixed as indicated in previous comments in Rev. 636658. Now a BundleResource is only created, if ... * the path addresses an existing Bundle resource file or * the path addresses an existing Bundle resource folder and no repository item of the same name exists Otherwise, particularly in case of a Bundle resource folder hiding an existing repository item, no BundleResource is returned. > Bundle based Resource should be able to adapt to Repository Item > > > Key: SLING-259 > URL: https://issues.apache.org/jira/browse/SLING-259 > Project: Sling > Issue Type: Improvement > Components: Resource >Reporter: Dominique Jäggi >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When using bundle based Resources, items stored in the repository may be > hidden by the actual bundle resources. This is ok for file-like resources but > might be problematic in some situations for folders. > It would probably be helpfull, if bundle based resources would be able to > adapt to repository items if an item would exist at the path of the resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-323) Provide Jackrabbit API over RMI
[ https://issues.apache.org/jira/browse/SLING-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-323. --- Resolution: Fixed This can be closed for now as the Jackrabbit API is provided over RMI with using the latest Jackrabbit RMI library snapshot. > Provide Jackrabbit API over RMI > --- > > Key: SLING-323 > URL: https://issues.apache.org/jira/browse/SLING-323 > Project: Sling > Issue Type: Bug > Components: Repository >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Discusses as a problem based on the problem report by Vidar Ramdal on the dev > list [1]: > When Sling accesses a repository over RMI, node type registration fails > blatantly because the Sling RMI layer does not expose the Jackrabbit API > which is required for node type registration as done in Sling. > BTW: It turns out, that the original problem reported by Vidar most probably > is not an RMI problem, but a problem starting the TransientRepository on the > server side. > [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg03279.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-233) UjaxPostServlet should care to find an appropriate parent location for new nodes
[ https://issues.apache.org/jira/browse/SLING-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578211#action_12578211 ] Bertrand Delacretaz commented on SLING-233: --- Agree about wontfix, we can always reopen if the need comes > UjaxPostServlet should care to find an appropriate parent location for new > nodes > > > Key: SLING-233 > URL: https://issues.apache.org/jira/browse/SLING-233 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > When the UjaxPostServlet is called with an URL not resolving to an existing > resource, it just takes the missing resource path as the path of the node to > handle. > This may be a problem in case the ResourceResolver applies a mapping, such as: >/* ==> /content/* - try every path below /content/ >/* ==> /* - try every path unmodified > The intent of this is to first locate resources below the /content/ node and > only then unmodified. This way, the primary web site content may be stored > below /content but still be accessed as if it would be located just below > root. > Consider a POST request to /home/intro where the /home page does not exist > (yet). In this case currently, the /home/intro node would be created as > requested. If the /home page would be located at /content/home, the new node > would be created as /content/home/intro. > To work around this problem, I suggest to modify the servlet, such that in > the case of a missing resource such as /home/intro or /home/* the request > path is walked up until a resource can be resolved. In the example POST to > /home/intro with a missing /content/home resource, the post servlet would go > up to "/" which resolves to "/content" (assuming /content exists of course) > and thus would create the new node under /content/home automatically also > creating the intermediate /content/home node. > To be able to still create nodes at the exact path, I propose the > introduction of a control parameter ujax:parentMatch: > ujax:parentMatch == "exact" --> use the request path as node path as > is without resolving a parent > ujax:parentMatch == "resolve" --> resolve a parent node and have > intermediate nodes created accordingly > The default value if the ujax:parentMatch parameter is missing is "resolve". > WDYT ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-307) JsonQueryServlet
[
https://issues.apache.org/jira/browse/SLING-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz closed SLING-307.
-
Verified that all tests pass, closing, thanks!
> JsonQueryServlet
>
>
> Key: SLING-307
> URL: https://issues.apache.org/jira/browse/SLING-307
> Project: Sling
> Issue Type: New Feature
> Components: Default Servlets
>Reporter: Philipp Koch
>Assignee: Bertrand Delacretaz
> Fix For: 2.0.0
>
> Attachments: queryservlet.patch
>
>
> it would be nice to have a way to specify a jcr query in the url in order to
> query the underlying jcr repository.
> the attached patch works as follows:
> The new query servlet is called if the extension is ".json" and the selector
> is set to "query". you can pass following parameters in the url:
> statement: jcr query statement (XPATH or SQL)
> queryType: xpath or sql (of none is specified xpath is taken)
> property: specifies which property (relative path) has to be "put" into the
> result set (this parameter can be added multiple times)
> excerptPath: specifies the relative node path from where the excerpt has to
> be built.
> the result is returned as json string. e.g.:
> [
> {"name":"ee0","rep:excerpt()":"geometrixx/components/contentpage
> ...
> ee<\/fragment><\/excerpt>","jcr:path":"/content/ee0","jcr:score":"528","cq:content/jcr:title":"ee"},
> {"name":"news","rep:excerpt()":" ...
> geometrixx/components/contentpage ... ... ... ... news about
> geometrix<\/fragment><\/excerpt>","jcr:path":"/content/geometrixx/en/about/news","jcr:score":"521","cq:content/jcr:title":"News"}
> ]
> example query call:
> http://localhost:8080/sling/myhome.query.json?statement=//element(*,cq:Page)[jcr:contains(.,'sling')]/(rep:excerpt(.))&property=cq:content/jcr:title&excerptPath=cq:content
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-325) Add RequestDispatcherOptions.OPT_REQUEST_METHOD
[ https://issues.apache.org/jira/browse/SLING-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578219#action_12578219 ] Bertrand Delacretaz commented on SLING-325: --- > how about a 'forceGet' attribute with default to 'true' if not set ? I like this, and I'd even tend to suggest always forcing to GET for includes. Using includes to process POST or other requests (except HEAD maybe) sounds scary, but that's just a gut feeling, I don't have precise examples. So I'm ok for either a forceGet option or for always forcing GET without the option for now, and adding the option later if we ever need it. > Add RequestDispatcherOptions.OPT_REQUEST_METHOD > --- > > Key: SLING-325 > URL: https://issues.apache.org/jira/browse/SLING-325 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Tobias Bocanegra > > I'm facing a problem with POST handling in scripts. i have a 'main' script > that includes others (header, navigation, footer, etc.) using > . > now i have a html form that uses (multipart) POST that i want to handle > myself and not with the ujax post servlet. therefor i added a 'POST.jsp' > beside my 'html.jsp' of the main script. this works. now the problem is, that > all included resources that do not have a POST.jsp are rendered by the ujax > post servlet, which is not what i want. of course i can add POST.jsp to all > other scripts but that's a bit tiresome. > suggest to: > - add new RequestDispatcherOption OPT_REQUEST_METHOD that allows override of > the method (maybe limit to 'GET') > - extend the tag to take a 'method' attribute and default it > to GET, if absent (it would be tedious to specify the GET for every include, > so rather make it default). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: separating webapp and integration tests
On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...I only see a solution by splitting > the web app (to be compiled for pre-1.5) and the integration tests (to > be compiled for 1.5) I'd be ok with that, provided that doesn't make running or developing the tests harder. A related thing that has been on my mind for a while is to allow OSGi bundles to contain automated tests that could be executed via the Sling console or via a Sling test harness. That's probably not too hard to do, and that would allow the integration tests to be simply provided as a bundle, but I don't have cycles ATM to work on that. > ... OTOH it is also up to discussion, whether we implement SLING-190 at > all ?... I think it's good to have such startup environment checks, if that's not too "expensive". -Bertrand
Re: separating webapp and integration tests
Hi, Am Donnerstag, den 13.03.2008, 11:43 +0100 schrieb Bertrand Delacretaz: > On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > ...I only see a solution by splitting > > the web app (to be compiled for pre-1.5) and the integration tests (to > > be compiled for 1.5) > > I'd be ok with that, provided that doesn't make running or developing > the tests harder. > > A related thing that has been on my mind for a while is to allow OSGi > bundles to contain automated tests that could be executed via the > Sling console or via a Sling test harness. That's probably not too > hard to do, and that would allow the integration tests to be simply > provided as a bundle, but I don't have cycles ATM to work on that. That would be an interesting approache to splitting the integration tests and the web app: the tests are deployed as just another bundle and then there would be some runtime controller to start them ... > > > ... OTOH it is also up to discussion, whether we implement SLING-190 at > > all ?... > > I think it's good to have such startup environment checks, if that's > not too "expensive". The most expensive part was reverting the generics stuff we used in the app and webapp to plain old Java. That's it. The rest is not concerned, and this is actually quite nice ;-) Regards Felix > > -Bertrand
Re: separating webapp and integration tests
Felix Meschberger wrote: Hi, Am Donnerstag, den 13.03.2008, 11:43 +0100 schrieb Bertrand Delacretaz: On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: ...I only see a solution by splitting the web app (to be compiled for pre-1.5) and the integration tests (to be compiled for 1.5) I'd be ok with that, provided that doesn't make running or developing the tests harder. A related thing that has been on my mind for a while is to allow OSGi bundles to contain automated tests that could be executed via the Sling console or via a Sling test harness. That's probably not too hard to do, and that would allow the integration tests to be simply provided as a bundle, but I don't have cycles ATM to work on that. That would be an interesting approache to splitting the integration tests and the web app: the tests are deployed as just another bundle and then there would be some runtime controller to start them ... Not sure, if this helps, but the Spring Dynamic Modules stuff provides an extension to a junit test which automatically starts the osgi container (Felix, Equinox etc.), deploys the bundle, runs the tests and then shuts down everything. You can list additional bundles to be deployed. This looked very easy and nice to me, but I didn't had time to test drive it yet. Carsten ... OTOH it is also up to discussion, whether we implement SLING-190 at all ?... I think it's good to have such startup environment checks, if that's not too "expensive". The most expensive part was reverting the generics stuff we used in the app and webapp to plain old Java. That's it. The rest is not concerned, and this is actually quite nice ;-) Regards Felix -Bertrand -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling projects and mentors for GSoC?
I am really interested in building the JCR explorer based on Sling and dojo. And of course I would like to do it as a GSoC project. I appreciate, if you could provide with some more information and guidelines to refine this idea a little bit further. thanks in advance. BR, Thilina On Wed, Mar 12, 2008 at 10:51 PM, Bertrand Delacretaz < [EMAIL PROTECTED]> wrote: > On Wed, Mar 12, 2008 at 4:31 PM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: > > ... i would be happy to mentor the JCR explorer > > Cool! > > We'll need a committer to be the "official" mentor, but I think it is > ok to list you as a co-mentor, as you're an active member of the Sling > community. > > -Bertrand >
Re: Sling projects and mentors for GSoC?
Hi Thilina, this sounds like you could make use of the Sling Dojo classes I wrote: https://issues.apache.org/jira/browse/SLING-301 I am planning to improve them in the next two days, so I am very interested in your feedback. regards, Lars On 13.03.2008, at 12:24, Thilina Buddhika wrote: I am really interested in building the JCR explorer based on Sling and dojo. And of course I would like to do it as a GSoC project. I appreciate, if you could provide with some more information and guidelines to refine this idea a little bit further. thanks in advance. BR, Thilina On Wed, Mar 12, 2008 at 10:51 PM, Bertrand Delacretaz < [EMAIL PROTECTED]> wrote: On Wed, Mar 12, 2008 at 4:31 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: ... i would be happy to mentor the JCR explorer Cool! We'll need a committer to be the "official" mentor, but I think it is ok to list you as a co-mentor, as you're an active member of the Sling community. -Bertrand -- Lars Trieloff [EMAIL PROTECTED] http://weblogs.goshaky.com/weblogs/lars smime.p7s Description: S/MIME cryptographic signature
Re: How about a Sling http proxy extension?
Hi Betrand, http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/ProxyServlet.java should be the best starting point. Shindig provides a full implementation of OpenSocial, so this servlet is embedded into the rest of Shindig. Lars On 12.03.2008, at 14:28, Bertrand Delacretaz wrote: On Wed, Mar 12, 2008 at 2:14 PM, Lars Trieloff <[EMAIL PROTECTED]> wrote: ... can't we just re-use the effort made by the Shindig project, which implements such as proxy for OpenSocial support?... Maybe, do you have a link to that code? Note that a basic http proxy is simple to implement with HttpClient, but why not reuse external code if it's good. Also, my suggestion doesn't seem to be met with much enthusiasm, so I might not do it at this time ;-) -Bertrand -- Lars Trieloff [EMAIL PROTECTED] http://weblogs.goshaky.com/weblogs/lars smime.p7s Description: S/MIME cryptographic signature
Re: Sling projects and mentors for GSoC?
Sure. Great news. I am playing around with Sling and dojo these days. I'll give my feedback on them. BR, Thilina On Thu, Mar 13, 2008 at 5:23 PM, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi Thilina, > > this sounds like you could make use of the Sling Dojo classes I wrote: > https://issues.apache.org/jira/browse/SLING-301 > I am planning to improve them in the next two days, so I am very > interested in your feedback. > > regards, > > Lars > > On 13.03.2008, at 12:24, Thilina Buddhika wrote: > > > I am really interested in building the JCR explorer based on Sling > > and dojo. > > And of course I would like to do it as a GSoC project. > > > > I appreciate, if you could provide with some more information and > > guidelines > > to refine this idea a little bit further. > > > > thanks in advance. > > > > BR, > > Thilina > > > > On Wed, Mar 12, 2008 at 10:51 PM, Bertrand Delacretaz < > > [EMAIL PROTECTED]> wrote: > > > >> On Wed, Mar 12, 2008 at 4:31 PM, Tobias Bocanegra > >> <[EMAIL PROTECTED]> wrote: > >>> ... i would be happy to mentor the JCR explorer > >> > >> Cool! > >> > >> We'll need a committer to be the "official" mentor, but I think it is > >> ok to list you as a co-mentor, as you're an active member of the > >> Sling > >> community. > >> > >> -Bertrand > >> > > -- > Lars Trieloff > [EMAIL PROTECTED] > http://weblogs.goshaky.com/weblogs/lars > >
Re: How about a Sling http proxy extension?
On Thu, Mar 13, 2008 at 12:57 PM, Lars Trieloff <[EMAIL PROTECTED]> wrote: > ... > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/ProxyServlet.java > Ok thanks, I'll have a look if we get to implement this. -Bertrand
Listing node children
What is the currently recommended way of listing a node's children from a rendering script (.esp)? >From examining the Sling source code, it seems that resource.resourceResolver.getResource should get me something, but I can't seem to iron out the oddities. Also, is there any documentation somewhere, on the variables that are available for scripting? -- Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: Listing node children
Hi Vidar, Am Donnerstag, den 13.03.2008, 13:49 +0100 schrieb Vidar Ramdal: > What is the currently recommended way of listing a node's children > from a rendering script (.esp)? To enumerate the children of a Resource you use the ResourceResolver.listChildren(resource) method. In esp, this would be something like: var children = request.resourceResolver.listChildren(request.resource); to list the children of the resource underlying the request. > > >From examining the Sling source code, it seems that > resource.resourceResolver.getResource should get me something, but I > can't seem to iron out the oddities. getResource just gets you access to a specific resource. > > Also, is there any documentation somewhere, on the variables that are > available for scripting? The only "documentation" so far is the constants defined in the SlingBindings class. Hope this helps. Regards Felix
Re: Sling projects and mentors for GSoC?
Hi Thilina, On Thu, Mar 13, 2008 at 12:24 PM, Thilina Buddhika <[EMAIL PROTECTED]> wrote: > ...I am really interested in building the JCR explorer based on Sling and > dojo. > And of course I would like to do it as a GSoC project Good to know! Note that GSoC hasn't officially started for us, the participating organizations will be confirmed on March 17th. But that shouldn't prevent you from starting to study the problem if you want - I'd suggest taking a look at existing JCR explorers, there are some links to such tools at http://wiki.apache.org/jackrabbit/JcrLinks . The basic features of a JCR explorer are IMHO to allow browsing the repository, CRUD operations on nodes and properties, searching nodes, file uploads and downloads, and admin features. I think for Sling, this project could as well be an example/reference application as a useful tool. -Bertrand
Re: Listing node children
On Thu, Mar 13, 2008 at 1:54 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > >... Also, is there any documentation somewhere, on the variables that are > > available for scripting? > > The only "documentation" so far is the constants defined in the > SlingBindings class And the tests: the .esp and .ecma scripts under http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/webapp/src/test/resources/integration-test/ provide some additional examples. -Bertrand
Re: Sling projects and mentors for GSoC?
On Thu, Mar 13, 2008 at 2:08 PM, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > > ... How about defining a formal remote protocol for JCR instead? ... Doesn't have to be "instead" IMHO, that sounds like a totally different project, isn't it? > ...having a defined, formal > protocol to interact with a JCR repository would be ideal. I'm > thinking something similar to webdav but more appropriate for JCR > repositories Do you mean formalizing/clarifying what Sling does with ujax, etc? Or rather defining a new protocol, REST-based I assume? If you're thinking about the latter, I'm not sure if it's in scope for Sling, that might be more a Jackrabbit project, IMHO. -Bertrand
Re: Sling projects and mentors for GSoC?
On 13 Mar 2008, at 12:59, Bertrand Delacretaz wrote: The basic features of a JCR explorer are IMHO to allow browsing the repository, CRUD operations on nodes and properties, searching nodes, file uploads and downloads, and admin features. I think for Sling, this project could as well be an example/reference application as a useful tool. How about defining a formal remote protocol for JCR instead? A JCR explorer is of course a useful tool, but having a defined, formal protocol to interact with a JCR repository would be ideal. I'm thinking something similar to webdav but more appropriate for JCR repositories. -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Created: (SLING-326) Rena me µjax to "sling client library"
Rename µjax to "sling client library" - Key: SLING-326 URL: https://issues.apache.org/jira/browse/SLING-326 Project: Sling Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor As discussed recently [1], reducing the number of names for the different sling components should help people make sense of it. The idea is to rename the µjax stuff to "sling client library", and I suppose the UjaxPostServlet can be renamed to SlingPostServlet? There were some discussions about using "catapult" for the name, but that's so good a name that we'll keep it in store for later ;-) [1] http://markmail.org/message/5yeuwlbsj6m7da6o -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Heading a first Releas: Part I SNAPSHOT Dependencies
On Thu, Mar 13, 2008 at 8:34 AM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ... What about the ujax renaming David suggested recently? I think this is > something we should do before a first release. (it shouldn't be that > hard) Agreed, created SLING-326 for that. Bertrand
Re: Listing node children
On 3/13/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Thu, Mar 13, 2008 at 1:54 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > >... Also, is there any documentation somewhere, on the variables that are > > > > available for scripting? > > The only "documentation" so far is the constants defined in the > > SlingBindings class > And the tests: the .esp and .ecma scripts under > > http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/webapp/src/test/resources/integration-test/ > > provide some additional examples. Thank you both, that's helpful. Now, let's say I have a child iterator: var iterator = resource.resourceResolver.listChildren(r); ... and I know that the children will be JCR nodes, how can I output (e.g.) the title attribute of all child nodes? As you may have suspected, I'd want to produce a menu, like Title of child 1 Title of child 2 ... -- Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: Heading a first Releas: Part I SNAPSHOT Dependencies
And I think we should release the felix configadmin 1.0.1 before. I can take care of that tomorrow. Carsten Carsten Ziegeler wrote: Felix Meschberger wrote: Hi all, I am trying to head at a first Sling release now, so I am starting to look at our dependencies to ensure, we don't have any external SNAPSHOT dependencies. In a second mail, I will wrap up JIRA issues which are currently still open to select the issues, we deem required to be fixed before a release. First let's see the SNAPSHOT dependencies: org.apache.felix:maven-scr-plugin:1.0.4-SNAPSHOT - vote for 1.0.4 release under way, so this will be resolved shortly org.apache.felix.commons:org.apache.felix.commons.commons-collections:3.2.0-0001-SNAPSHOT - Unreleased wrapping provided by Apache Felix org.apache.jackrabbit:jackrabbit-jcr-rmi:1.5-SNAPSHOT - Required for fixes to JCR-1406 and JCR-1454 - I will try to get a 1.4.1 release with backported fixes org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT - library is itself an OSGi Bundle - I will try to get a 1.4.1 release with backported fix Unless I missed a dependency, we are very close to be SNAPSHOT dependency free. I will try to get the above mentioned releases from the Jackrabbit project. Carsten, do you know anything about the an imminent release of the Jakarta Commons Collections library as an OSGi bundle ? Yes or .. no :) There is a release of lang upcomming in the near future, but a new release of collections is not visible atm. Am I missing something ? What about the ujax renaming David suggested recently? I think this is something we should do before a first release. (it shouldn't be that hard). The scheduler bundle requires commons beanutils and digester (and perhaps one more). I'm planning to include these into the bundle today. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling projects and mentors for GSoC?
On 13 Mar 2008, at 13:18, Bertrand Delacretaz wrote: On Thu, Mar 13, 2008 at 2:08 PM, Torgeir Veimo <[EMAIL PROTECTED]> wrote: ... How about defining a formal remote protocol for JCR instead? ... Doesn't have to be "instead" IMHO, that sounds like a totally different project, isn't it? ...having a defined, formal protocol to interact with a JCR repository would be ideal. I'm thinking something similar to webdav but more appropriate for JCR repositories Do you mean formalizing/clarifying what Sling does with ujax, etc? Or rather defining a new protocol, REST-based I assume? If you're thinking about the latter, I'm not sure if it's in scope for Sling, that might be more a Jackrabbit project, IMHO. I was thinking more of in the context of GSoC. Sling would be an ideal environment to implement a prototype for such a protocol. -- Torgeir Veimo [EMAIL PROTECTED]
Re: Listing node children
Hi Vidal,
Am Donnerstag, den 13.03.2008, 14:34 +0100 schrieb Vidar Ramdal:
> On 3/13/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 13, 2008 at 1:54 PM, Felix Meschberger <[EMAIL PROTECTED]>
> > wrote:
> > > >... Also, is there any documentation somewhere, on the variables that
> > are
> >
> > > > available for scripting?
> > > The only "documentation" so far is the constants defined in the
> > > SlingBindings class
> > And the tests: the .esp and .ecma scripts under
> >
> > http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/webapp/src/test/resources/integration-test/
> >
> > provide some additional examples.
>
> Thank you both, that's helpful.
>
> Now, let's say I have a child iterator:
> var iterator = resource.resourceResolver.listChildren(r);
>
> ... and I know that the children will be JCR nodes, how can I output
> (e.g.) the title attribute of all child nodes?
>
> As you may have suspected, I'd want to produce a menu, like
>
> Title of child 1
> Title of child 2
> ...
>
You have two options : (1) Stay with Resources or (2) access the node.
To stay with resources you may do for each child resource:
var child = ...
var title = resourceResolver.getResource(child, "title");
if (title != null) {
var titleString = title.adaptTo(java.lang.String);
}
the trick here is, that the title resource represents a property and
with the adaptTo method you get the string value of that property.
The second option - using the node - you do
var child = ...
var childNode = child.adaptTo(Packages.javax.jcr.Node);
if (childNode != null && childNode.hasProperty("title")) {
var titleString =
childNode.getProperty("title").getString();
}
I personally prefer the first approach because it stays within a single
paradigm and you do not have to care about RepositoryExceptions being
thrown by directly accessing the node. Your mileage may vary, though.
Regards
Felix
>
>
Re: Sling projects and mentors for GSoC?
On Thu, Mar 13, 2008 at 2:47 PM, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > ... Sling would be an ideal environment to implement a prototype for such > a protocol Ok, I see the idea. I'll be busy with the other projects I guess, but if another committer wants to step up to be the official mentor on this (community members are welcome to help anyway), why not. -Bertrand
Re: Listing node children
On Thu, Mar 13, 2008 at 2:47 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> ...The second option - using the node - you do
>
> var child = ...
> var childNode = child.adaptTo(Packages.javax.jcr.Node);
> if (childNode != null && childNode.hasProperty("title")) {
> var titleString =
> childNode.getProperty("title").getString();
> }...
This is IMHO ugly, and the Resource option that you suggest is quite
involved as well for a simple thing.
To be consistent with the way we handle nodes in server-side
javascript I think this should be written like (warning that code
won't work now):
var iterator = resource.resourceResolver.listChildren(r);
var r = iterator.next();
var titleString = r.node.title;
Which would mean re-adding the ScriptableResource.jsGet_Node() method
that was removed in revision 631980
-Bertrand
[jira] Commented: (SLING-326) Ren ame µjax to "sling client library"
[ https://issues.apache.org/jira/browse/SLING-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578306#action_12578306 ] Carsten Ziegeler commented on SLING-326: I think we should also rename the "ujax:" prefix to "sling:" for the request parameters Btw, the sling client library is one of the greatest things on earth, so it deserves the name catapult. > Rename µjax to "sling client library" > - > > Key: SLING-326 > URL: https://issues.apache.org/jira/browse/SLING-326 > Project: Sling > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > > As discussed recently [1], reducing the number of names for the different > sling components should help people make sense of it. > The idea is to rename the µjax stuff to "sling client library", and I suppose > the UjaxPostServlet can be renamed to SlingPostServlet? > There were some discussions about using "catapult" for the name, but that's > so good a name that we'll keep it in store for later ;-) > [1] http://markmail.org/message/5yeuwlbsj6m7da6o -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
faq link broken
Hi I've seen that the faq link was broken in your home page. I've updated it in the confluence but you should export the space in order to fix it. Regards. -- David Calavera http://www.thinkincode.net
Re: Heading a first Releas: Part I SNAPSHOT Dependencies
sling releaseAm Donnerstag, den 13.03.2008, 14:34 +0100 schrieb Carsten Ziegeler: > And I think we should release the felix configadmin 1.0.1 before. I can > take care of that tomorrow. If we would want to include the "race-condition fix", yes. Thanks. Regards Felix > > Carsten > > Carsten Ziegeler wrote: > > Felix Meschberger wrote: > >> Hi all, > >> > >> I am trying to head at a first Sling release now, so I am starting to > >> look at our dependencies to ensure, we don't have any external SNAPSHOT > >> dependencies. In a second mail, I will wrap up JIRA issues which are > >> currently still open to select the issues, we deem required to be fixed > >> before a release. > >> > >> First let's see the SNAPSHOT dependencies: > >> > >> org.apache.felix:maven-scr-plugin:1.0.4-SNAPSHOT > >>- vote for 1.0.4 release under way, so this will be resolved > >> shortly > >> > >> org.apache.felix.commons:org.apache.felix.commons.commons-collections:3.2.0-0001-SNAPSHOT > >> > >> > >>- Unreleased wrapping provided by Apache Felix > >> > >> org.apache.jackrabbit:jackrabbit-jcr-rmi:1.5-SNAPSHOT > >>- Required for fixes to JCR-1406 and JCR-1454 > >>- I will try to get a 1.4.1 release with backported fixes > >> > >> org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT > >>- library is itself an OSGi Bundle > >>- I will try to get a 1.4.1 release with backported fix > >> > >> Unless I missed a dependency, we are very close to be SNAPSHOT > >> dependency free. I will try to get the above mentioned releases from the > >> Jackrabbit project. > >> > >> Carsten, do you know anything about the an imminent release of the > >> Jakarta Commons Collections library as an OSGi bundle ? > > Yes or .. no :) There is a release of lang upcomming in the near future, > > but a new release of collections is not visible atm. > > > >> > >> Am I missing something ? > > What about the ujax renaming David suggested recently? I think this is > > something we should do before a first release. (it shouldn't be that hard). > > > > The scheduler bundle requires commons beanutils and digester (and > > perhaps one more). I'm planning to include these into the bundle today. > > > > Carsten > >
Re: Listing node children
Hi,
Am Donnerstag, den 13.03.2008, 15:10 +0100 schrieb Bertrand Delacretaz:
> On Thu, Mar 13, 2008 at 2:47 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
>
> > ...The second option - using the node - you do
> >
> > var child = ...
> > var childNode = child.adaptTo(Packages.javax.jcr.Node);
> > if (childNode != null && childNode.hasProperty("title")) {
> > var titleString =
> > childNode.getProperty("title").getString();
> > }...
>
> This is IMHO ugly, and the Resource option that you suggest is quite
> involved as well for a simple thing.
ok, ok, I am biased ;-) you may write the second one as follows:
var child = ...
var childNode = child.adaptTo(Packages.javax.jcr.Node);
if (childNode != null) {
var titleString = childNode.title;
}
This is certainly less ugly.
Still we are bound to the Resource API, thus the adaptTo method remains.
Though I cannot see the uglyness (this may be why the old romans said
"de gustibus non est disputandum").
Regards
Felix
Re: Listing node children
On 3/13/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 2:47 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> > ...The second option - using the node - you do
> > var child = ...
> > var childNode = child.adaptTo(Packages.javax.jcr.Node);
> > if (childNode != null && childNode.hasProperty("title")) {
> > var titleString =
> > childNode.getProperty("title").getString();
>
> > }...
>
> This is IMHO ugly, and the Resource option that you suggest is quite
> involved as well for a simple thing.
>
> To be consistent with the way we handle nodes in server-side
> javascript I think this should be written like (warning that code
> won't work now):
>
>
> var iterator = resource.resourceResolver.listChildren(r);
>
> var r = iterator.next();
> var titleString = r.node.title;
>
> Which would mean re-adding the ScriptableResource.jsGet_Node() method
> that was removed in revision 631980
Yes, please :)
This kind of operation (listing children as a menu) will be a fairly
common task - at least in my world.
--
Vidar S. Ramdal <[EMAIL PROTECTED]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: faq link broken
Hi David, Am Donnerstag, den 13.03.2008, 15:29 +0100 schrieb David Calavera: > Hi > > I've seen that the faq link was broken in your home page. I've updated it in > the confluence but you should export the space in order to fix it. Thanks for pointing this out. Unfortunately, this now completely destroys the link. The FAQ is on our community wiki (SLING) not on our site wikie (SLINGxSITE). I now changed this link to point to the correct link in confluence. ... and exported the site. Will take some time to get to the front, though... Regards Felix
Re: Sling projects and mentors for GSoC?
Hi Torgeir, Am Donnerstag, den 13.03.2008, 13:08 + schrieb Torgeir Veimo: > On 13 Mar 2008, at 12:59, Bertrand Delacretaz wrote: > > > The basic features of a JCR explorer are IMHO to allow browsing the > > repository, CRUD operations on nodes and properties, searching nodes, > > file uploads and downloads, and admin features. > > > > I think for Sling, this project could as well be an example/reference > > application as a useful tool. > > > How about defining a formal remote protocol for JCR instead? A JCR > explorer is of course a useful tool, but having a defined, formal > protocol to interact with a JCR repository would be ideal. I'm > thinking something similar to webdav but more appropriate for JCR > repositories. I am not sure, whether I understand you correctly. Currently the Jackrabbit protocol has an RMI library, which allows plain-JCR remoting over RMI. In addition there is a simple WebDAV servlet, which allows filesystem-like access over WebDAV to the repository and there is a JCR WebDAV servlet, which in fact remotes the JCR API over WebDAV using defined WebDAV functionality such as DASL etc. So, I would be very interested what we could add here ;-) As such, I would be willing to mentor such task. Regards Felix
[jira] Created: (SLING-327) SingAuthenticator: improve Repository sanity check
SingAuthenticator: improve Repository sanity check -- Key: SLING-327 URL: https://issues.apache.org/jira/browse/SLING-327 Project: Sling Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Currently the SlingAuthenticator sometimes behaves in funny ways if the Repository is not available, or not accepting logins for some reason. If anonymous access is allowed, for example, a login box might appear if the repository becomes unavailable, which makes things confusing. The attached patch improves the situation by verifying that an admin session can be obtained from the Repository, and throws MissingRepositoryException if not. This should allow better handling of Repository problems in higher application layers. I'm not sure about all the implications - can we assume that an admin session is required for things to work? Please review the patch before I apply it, or feel free to apply it, as I'll be mostly offline until after Easter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-327) SingAuthenticator: improve Repository sanity check
[ https://issues.apache.org/jira/browse/SLING-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-327: -- Attachment: SLING-327.patch > SingAuthenticator: improve Repository sanity check > -- > > Key: SLING-327 > URL: https://issues.apache.org/jira/browse/SLING-327 > Project: Sling > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: SLING-327.patch > > > Currently the SlingAuthenticator sometimes behaves in funny ways if the > Repository is not available, or not accepting logins for some reason. If > anonymous access is allowed, for example, a login box might appear if the > repository becomes unavailable, which makes things confusing. > The attached patch improves the situation by verifying that an admin session > can be obtained from the Repository, and throws MissingRepositoryException if > not. > This should allow better handling of Repository problems in higher > application layers. > I'm not sure about all the implications - can we assume that an admin session > is required for things to work? > Please review the patch before I apply it, or feel free to apply it, as I'll > be mostly offline until after Easter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-328) access to node props in esp
access to node props in esp
---
Key: SLING-328
URL: https://issues.apache.org/jira/browse/SLING-328
Project: Sling
Issue Type: Bug
Reporter: Michael Marth
My .esp looks like
for (var i in currentNode.getNodes()) {
if(currentNode.getNodes()[i].getProperty("approved").getString() ==
"true") {
...
Bertrand tells me that in the second line this should work as well:
if(currentNode.getNodes()[i].approved (...)
It does not give an exception but the property is undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-329) cannot access node when node name is a number
cannot access node when node name is a number
-
Key: SLING-329
URL: https://issues.apache.org/jira/browse/SLING-329
Project: Sling
Issue Type: Bug
Reporter: Michael Marth
Priority: Minor
the line
currentNode.getNodes()[i].getProperty("approved").getString()
gives
TypeError: Cannot call method "getProperty" of undefined
(/apps/tss/list/html.esp#8) (500)
If the node name consists of numbers only (like "11" - but "1" is OK)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-301) Dojo Classes for accessing the repository via the µjax protocol
[ https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-301: Attachment: SlingPropertyStore.js Updated the naming, that's all. To be placed at /dojo/dojox/data > Dojo Classes for accessing the repository via the µjax protocol > --- > > Key: SLING-301 > URL: https://issues.apache.org/jira/browse/SLING-301 > Project: Sling > Issue Type: Improvement > Components: ujax >Reporter: Lars Trieloff >Priority: Minor > Attachments: dojo-ujax.tar.gz, SlingNodeStore.js, > SlingPropertyStore.js > > > I've created two Dojo Store implementations that use the µjax protocol to > communicate with the repository. The UJaxNodeStore implements a read-only > hierarchical store (I am planning to add write support later on) that can be > used to read properties and children of a node. The UJaxPropertyStore > implements a read-write flat store for accessing the properties of a node. > The Store showcases a high-level integration with a full-fledged AJAX toolkit > that allows easy integration with an existing widget system. > Using these store classes, it was easy to create an example repository > browser that uses a tree control and a grid control to browse the resource > tree and allows to create new and change existing properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-301) Dojo Classes for accessing the repository via the µjax protocol
[ https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-301: Attachment: SlingNodeStore.js to be placed at /dojo/dojox/data Updated the node store to the new naming regulation and it supports querying only child nodes of a node, which is very helpful if you want to get a tabular list of child nodes and their properties. Also: write support added. > Dojo Classes for accessing the repository via the µjax protocol > --- > > Key: SLING-301 > URL: https://issues.apache.org/jira/browse/SLING-301 > Project: Sling > Issue Type: Improvement > Components: ujax >Reporter: Lars Trieloff >Priority: Minor > Attachments: dojo-ujax.tar.gz, SlingNodeStore.js, > SlingPropertyStore.js > > > I've created two Dojo Store implementations that use the µjax protocol to > communicate with the repository. The UJaxNodeStore implements a read-only > hierarchical store (I am planning to add write support later on) that can be > used to read properties and children of a node. The UJaxPropertyStore > implements a read-write flat store for accessing the properties of a node. > The Store showcases a high-level integration with a full-fledged AJAX toolkit > that allows easy integration with an existing widget system. > Using these store classes, it was easy to create an example repository > browser that uses a tree control and a grid control to browse the resource > tree and allows to create new and change existing properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-301) Dojo Classes for accessing the repository via the µjax protocol
[
https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Trieloff updated SLING-301:
Attachment: demo4.html
to be placed (optionally) at /dojo/dojox/data/demo
simple example showing how to use the query="{level : 2}" parameter on node
stores to get a table view of child nodes.
> Dojo Classes for accessing the repository via the µjax protocol
> ---
>
> Key: SLING-301
> URL: https://issues.apache.org/jira/browse/SLING-301
> Project: Sling
> Issue Type: Improvement
> Components: ujax
>Reporter: Lars Trieloff
>Priority: Minor
> Attachments: demo.html, demo2.html, demo4.html, dojo-ujax.tar.gz,
> SlingNodeStore.js, SlingPropertyStore.js
>
>
> I've created two Dojo Store implementations that use the µjax protocol to
> communicate with the repository. The UJaxNodeStore implements a read-only
> hierarchical store (I am planning to add write support later on) that can be
> used to read properties and children of a node. The UJaxPropertyStore
> implements a read-write flat store for accessing the properties of a node.
> The Store showcases a high-level integration with a full-fledged AJAX toolkit
> that allows easy integration with an existing widget system.
> Using these store classes, it was easy to create an example repository
> browser that uses a tree control and a grid control to browse the resource
> tree and allows to create new and change existing properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-301) Dojo Classes for accessing the repository via the µjax protocol
[ https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-301: Attachment: demo.html to be placed (optionally) at /dojo/dojox/data/demo simple example showing how to use queries in the NodeStore. > Dojo Classes for accessing the repository via the µjax protocol > --- > > Key: SLING-301 > URL: https://issues.apache.org/jira/browse/SLING-301 > Project: Sling > Issue Type: Improvement > Components: ujax >Reporter: Lars Trieloff >Priority: Minor > Attachments: demo.html, demo2.html, demo4.html, dojo-ujax.tar.gz, > SlingNodeStore.js, SlingPropertyStore.js > > > I've created two Dojo Store implementations that use the µjax protocol to > communicate with the repository. The UJaxNodeStore implements a read-only > hierarchical store (I am planning to add write support later on) that can be > used to read properties and children of a node. The UJaxPropertyStore > implements a read-write flat store for accessing the properties of a node. > The Store showcases a high-level integration with a full-fledged AJAX toolkit > that allows easy integration with an existing widget system. > Using these store classes, it was easy to create an example repository > browser that uses a tree control and a grid control to browse the resource > tree and allows to create new and change existing properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-301) Dojo Classes for accessing the repository via the µjax protocol
[ https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-301: Attachment: demo2.html to be placed (optionally) at /dojo/dojox/data/demo Complex example showing tree browser and two grids using the NodeStore in action. > Dojo Classes for accessing the repository via the µjax protocol > --- > > Key: SLING-301 > URL: https://issues.apache.org/jira/browse/SLING-301 > Project: Sling > Issue Type: Improvement > Components: ujax >Reporter: Lars Trieloff >Priority: Minor > Attachments: demo2.html, dojo-ujax.tar.gz, SlingNodeStore.js, > SlingPropertyStore.js > > > I've created two Dojo Store implementations that use the µjax protocol to > communicate with the repository. The UJaxNodeStore implements a read-only > hierarchical store (I am planning to add write support later on) that can be > used to read properties and children of a node. The UJaxPropertyStore > implements a read-write flat store for accessing the properties of a node. > The Store showcases a high-level integration with a full-fledged AJAX toolkit > that allows easy integration with an existing widget system. > Using these store classes, it was easy to create an example repository > browser that uses a tree control and a grid control to browse the resource > tree and allows to create new and change existing properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-302) Create a bundle providing Dojo as resources
[ https://issues.apache.org/jira/browse/SLING-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Trieloff updated SLING-302: Attachment: dojo-release-1.0.2.zip This is dojo without any tests and demos, which reduces the size of the zip file by 50%. Perhaps this is better suited for creating a bundle. > Create a bundle providing Dojo as resources > --- > > Key: SLING-302 > URL: https://issues.apache.org/jira/browse/SLING-302 > Project: Sling > Issue Type: New Feature >Reporter: Felix Meschberger > Attachments: dojo-release-1.0.2.zip > > > We have two contributions which provide client-side application (parts) both > based on the dojo toolkit [1]. To make it easier to integrate these two > contributions and to enable future works in this area, I suggest we create a > bundle, which exposes dojo as bundle resources for use by different client > side apps. > [1] http://dojotoolkit.org/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling projects and mentors for GSoC?
On 13 Mar 2008, at 15:49, Felix Meschberger wrote: How about defining a formal remote protocol for JCR instead? A JCR explorer is of course a useful tool, but having a defined, formal protocol to interact with a JCR repository would be ideal. I'm thinking something similar to webdav but more appropriate for JCR repositories. I am not sure, whether I understand you correctly. Currently the Jackrabbit protocol has an RMI library, which allows plain-JCR remoting over RMI. In addition there is a simple WebDAV servlet, which allows filesystem-like access over WebDAV to the repository and there is a JCR WebDAV servlet, which in fact remotes the JCR API over WebDAV using defined WebDAV functionality such as DASL etc. The webdav protocol doesn't map fully to the JCR data model. And RMI is not really that useful when the client is not a Java client. But I guess it opens up a lot of questions, I guess. How do you send JCR data over the wire? XML or JSON? -- Torgeir Veimo [EMAIL PROTECTED]
JCR meetup in Amsterdam on April 8th
Hi all, [Sorry for the duplicate if you already saw this on the Jackrabbit users mailing list.] In a few weeks I and many other Jackrabbit and Sling people will be attending the ApacheCon EU in Amsterdam [1], and I'd like to take the opportunity to organize a community meeting for JCR people. On Tuesday, April 8th, we have a chance of organizing a JCR meetup for everyone interested in JCR, Jackrabbit, and/or Sling. The meetup would be free to everyone and wouldn't require attendance at the ApacheCon. We could do JCR training, present and discuss different JCR deployment projects, case studies, and other stuff, and generally get to know each other better. Everyone is free and welcome to propose ideas for short presentations, discussion topics, and other things you'd be interested in seeing. Let me know if you can join us in Amsterdam and would be interested in attending such a meetup! [1] http://www.eu.apachecon.com/eu2008/ BR, Jukka Zitting
Re: Sling projects and mentors for GSoC?
> >> How about defining a formal remote protocol for JCR instead? A JCR > >> explorer is of course a useful tool, but having a defined, formal > >> protocol to interact with a JCR repository would be ideal. I'm > >> thinking something similar to webdav but more appropriate for JCR > >> repositories. > > > > I am not sure, whether I understand you correctly. Currently the > > Jackrabbit protocol has an RMI library, which allows plain-JCR > > remoting > > over RMI. In addition there is a simple WebDAV servlet, which allows > > filesystem-like access over WebDAV to the repository and there is a > > JCR > > WebDAV servlet, which in fact remotes the JCR API over WebDAV using > > defined WebDAV functionality such as DASL etc. > > > > The webdav protocol doesn't map fully to the JCR data model. And RMI > is not really that useful when the client is not a Java client. > > But I guess it opens up a lot of questions, I guess. How do you send > JCR data over the wire? XML or JSON? afaik there are already some drafts of implementing the JCR SPI using rjax. but this would rather be a jackrabbit GSoC topic, right? regards, toby -- -< [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 >---
