Re: [jira] Updated: (SLING-301) Dojo Clas ses for accessing the repository via the µjax protocol
Hi Rory Thanks for proividing the patch. I have created a new issue for the application of this patch [1]. Generally an issue, which has been closed should not be worked on anymore and a new issue should be created instead. This helps tracking down problems very much. Thanks for your comprehension. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-792 Rory Douglas (JIRA) schrieb: > [ > https://issues.apache.org/jira/browse/SLING-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Rory Douglas updated SLING-301: > --- > > Attachment: dojo.sling.patch.20081221.zip > > Updates to SlingNodeStore & SlingPropertyStore to work with Dojo 1.2, plus > feature enhancements > >> 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: Servlets Post >>Reporter: Lars Trieloff >>Assignee: Felix Meschberger >>Priority: Minor >> Attachments: demo.html, demo2.html, demo4.html, dojo-ujax.tar.gz, >> dojo.sling.patch.20081221.zip, 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. >
[jira] Created: (SLING-793) Improve property file includes
Improve property file includes -- Key: SLING-793 URL: https://issues.apache.org/jira/browse/SLING-793 Project: Sling Issue Type: Improvement Affects Versions: Launchpad Base 2.0.2 Reporter: Carsten Ziegeler Fix For: Launchpad Base 2.0.4 To include own property files with startup information, an include statement needs to be added to the sling.properties file. An exception is the "jcr-client.properties" file which is a hard-coded include in launchpad. It would be nice to be able to add own property files by convention instead of configuration. This would allow to use the sling.properties from launchpad base untouched by just adding additional files. I think the convention could use some filename conventions, so all files names "*-sling.properties" are included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12658460#action_12658460 ] Felix Meschberger commented on SLING-301: - Thanks for submitting this patch. I have created new issue SLING-792 for this enhancement. > 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: Servlets Post >Reporter: Lars Trieloff >Assignee: Felix Meschberger >Priority: Minor > Attachments: demo.html, demo2.html, demo4.html, dojo-ujax.tar.gz, > dojo.sling.patch.20081221.zip, 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] Created: (SLING-792) Adapt Sling(Node|Property)Store to Dojo 1.2 and some extensions
Adapt Sling(Node|Property)Store to Dojo 1.2 and some extensions --- Key: SLING-792 URL: https://issues.apache.org/jira/browse/SLING-792 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Felix Meschberger Assignee: Felix Meschberger Creating issue from the extension provided by Rory Douglas in https://issues.apache.org/jira/browse/SLING-301?focusedCommentId=12658420#action_12658420: The current store implementations don't work well with some common widgets (in particular ComboBox and FilteringSelect), in latest 1.2 Dojo releases. There are 2 problems: one, these widgets use the "query" parameter to pass a wildcarded fragment of user input to accomplish the autocomplete feature, but the SlingNodeStore/SlingPropertyStore currently only do exact string matches against the query; and two, this autocomplete query overwrites the filtering query specified on the store itself, when it really should be merged/ANDed with it. I've fixed the 2 classes to accomodate these wildcard queries (copied code from ItemFileReadStore). I've also made some changes/enhancements to the SlingNodeStore : 1) Moved 'level' out of 'query', put it in optional 'queryOptions' param instead (and renamed to 'depth') 2) Use common 'queryOptions' parameters 'deep' (along with 'depth') to control how hierarchy below target node is returned 2)a)If 'deep' is true, return all nodes below target up to 'depth'. If 'depth' not specified, use 'infinity'. b)If 'deep' is false, return only nodes at 'depth' below target node. If 'depth' not specified, use 1. So, with the following hierarchy, and store url="/test" /samplenodes /content/ /list1 /nodeA /subNodeA /list2 /nodeB /data /nodeC deep=true, depth=2 gives [samplenodes,content,list1,nodeA,list2,nodeB,nodeC,data] deep=true, no depth gives [samplenodes,content,list1,nodeA,subNodeA,nodeB,list2,nodeC,data] deep=false, depth=2 gives [nodeA,nodeB] deep=false, no depth gives [samplenodes] The behavior is consistent when used with ComboBox, but a little weird for Trees (where deep=false is default). Overriding deep to true for a tree can put the same node into the tree multiple times at different levels. Setting a depth for a ComboBox with deep=false sets the level from which nodes are retrieved, but for a Tree it only sets the depth at which the tree starts, it doesn't actually restrict the depth of the tree. So I've added another property 'treeDepth' (set in 'overrideDepth') which sets the the tree depth limit. This parameter has no effect on ComboBoxes since it's only enforced in the get/hasChildren methods. 3) Added attributes 'overrideDeep' and 'overrideDepth' to enable store to override values passed in via 'queryOptions' for 'deep' and 'depth'. Primarily useful since 'deep' defaults to 'false' for DataStores, but is hard-coded to 'true' in requests from ComboBox. 4) Merged specified store query with incoming queries from widgets before executing feth 5) Added attributes 'statement' and 'searchprops' to enable specifying a search query for the JsonQueryServlet, rather than a JsonRendererServlet URL. The modified files are attached as a zip (dojo.sling.patch.20081221.zip). Also includes a new demo page (demo4.html) and a set of sample nodes (samplenodes.json) used by the demo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: json on root node
I've noticed this too. From tracing through the code, I think the problem starts when writing out non-JCR Resources (like BundleResource or SyntheticResource). The dump(Resource, JSONWriter,int, int) method of JsonResourceWriter tries to adapt the given Resource to ValueMap, then a Map and finally a String. Those non-JCR Resources don't adapt to any of these, so the method just returns, rather than executing a JSONWriter.object()/JSONWriter.endObject() pair. I think this leaves the JSONWriter in the incorrect mode (set to 'o' in JSONWriter.key call at line 136), causing the failure on the subsequent node dump. If you have the dojo bundle installed (which renders the dojo javascript files as BundleResources) & try to dump http://localhost:/dojo.1.json, you'll see it renders the first file (AdapaterRegistry.js), but fails on the next. Unfortunately, I don't know enough about how this code is supposed to work to suggest a fix. Maybe those non-JCR resources should be adaptable to ValueMap or Map? Regards, Rory Torgeir Veimo wrote: Using http://localhost:8080/.json works, but trying http://localhost:8080/.infinity.json or http://localhost:8080/.1.json gives me an exception and error 500; org.apache.sling.commons.json.JSONException: Misplaced endArray. org.apache.sling.commons.json.io.JSONWriter.end(JSONWriter.java:203) org.apache.sling.commons.json.io.JSONWriter.endObject(JSONWriter.java:237) org.apache.sling.servlets.get.helpers.JsonResourceWriter.dump(JsonResourceWriter.java:128) org.apache.sling.servlets.get.helpers.JsonResourceWriter.dump(JsonResourceWriter.java:78) org.apache.sling.servlets.get.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:94) org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:262) How do I fetch child nodes of the root node in json format? This is with sling current trunk from last week.
json on root node
Using http://localhost:8080/.json works, but trying http://localhost:8080/.infinity.json or http://localhost:8080/.1.json gives me an exception and error 500; org.apache.sling.commons.json.JSONException: Misplaced endArray. org.apache.sling.commons.json.io.JSONWriter.end(JSONWriter.java:203) org.apache.sling.commons.json.io.JSONWriter.endObject(JSONWriter.java: 237) org .apache .sling .servlets.get.helpers.JsonResourceWriter.dump(JsonResourceWriter.java: 128) org .apache .sling .servlets.get.helpers.JsonResourceWriter.dump(JsonResourceWriter.java: 78) org .apache .sling .servlets .get.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:94) org .apache .sling .api .servlets .SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:262) How do I fetch child nodes of the root node in json format? This is with sling current trunk from last week. -- Torgeir Veimo torg...@pobox.com
[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 ] Rory Douglas updated SLING-301: --- Attachment: dojo.sling.patch.20081221.zip Updates to SlingNodeStore & SlingPropertyStore to work with Dojo 1.2, plus feature enhancements > 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: Servlets Post >Reporter: Lars Trieloff >Assignee: Felix Meschberger >Priority: Minor > Attachments: demo.html, demo2.html, demo4.html, dojo-ujax.tar.gz, > dojo.sling.patch.20081221.zip, 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] Commented: (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:comment-tabpanel&focusedCommentId=12658420#action_12658420 ] Rory Douglas commented on SLING-301: The current store implementations don't work well with some common widgets (in particular ComboBox and FilteringSelect), in latest 1.2 Dojo releases. There are 2 problems: one, these widgets use the "query" parameter to pass a wildcarded fragment of user input to accomplish the autocomplete feature, but the SlingNodeStore/SlingPropertyStore currently only do exact string matches against the query; and two, this autocomplete query overwrites the filtering query specified on the store itself, when it really should be merged/ANDed with it. I've fixed the 2 classes to accomodate these wildcard queries (copied code from ItemFileReadStore). I've also made some changes/enhancements to the SlingNodeStore : 1) Moved 'level' out of 'query', put it in optional 'queryOptions' param instead (and renamed to 'depth') 2) Use common 'queryOptions' parameters 'deep' (along with 'depth') to control how hierarchy below target node is returned 2)a)If 'deep' is true, return all nodes below target up to 'depth'. If 'depth' not specified, use 'infinity'. b)If 'deep' is false, return only nodes at 'depth' below target node. If 'depth' not specified, use 1. So, with the following hierarchy, and store url="/test" /samplenodes /content/ /list1 /nodeA /subNodeA /list2 /nodeB /data /nodeC deep=true, depth=2 gives [samplenodes,content,list1,nodeA,list2,nodeB,nodeC,data] deep=true, no depth gives [samplenodes,content,list1,nodeA,subNodeA,nodeB,list2,nodeC,data] deep=false, depth=2 gives [nodeA,nodeB] deep=false, no depth gives [samplenodes] The behavior is consistent when used with ComboBox, but a little weird for Trees (where deep=false is default). Overriding deep to true for a tree can put the same node into the tree multiple times at different levels. Setting a depth for a ComboBox with deep=false sets the level from which nodes are retrieved, but for a Tree it only sets the depth at which the tree starts, it doesn't actually restrict the depth of the tree. So I've added another property 'treeDepth' (set in 'overrideDepth') which sets the the tree depth limit. This parameter has no effect on ComboBoxes since it's only enforced in the get/hasChildren methods. 3) Added attributes 'overrideDeep' and 'overrideDepth' to enable store to override values passed in via 'queryOptions' for 'deep' and 'depth'. Primarily useful since 'deep' defaults to 'false' for DataStores, but is hard-coded to 'true' in requests from ComboBox. 4) Merged specified store query with incoming queries from widgets before executing feth 5) Added attributes 'statement' and 'searchprops' to enable specifying a search query for the JsonQueryServlet, rather than a JsonRendererServlet URL. The modified files are attached as a zip (dojo.sling.patch.20081221.zip). Also includes a new demo page (demo4.html) and a set of sample nodes (samplenodes.json) used by the demo. > 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: Servlets Post >Reporter: Lars Trieloff >Assignee: Felix Meschberger >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.
