[
https://issues.apache.org/jira/browse/SLING-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659602#action_12659602
]
Rory Douglas commented on SLING-792:
------------------------------------
This works for me, thanks! I'm not sure I have rights to close the issue
though...
> 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.
