#5873 closed enhancement (fixed)
[patch][cla] AndOrReadStore, AndOrWriteStore: New stores supporting complex queries
Reported by: | Frank Fortson | Owned by: | Jared Jurkiewicz |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | Data | Version: | 1.0 |
Keywords: | AndOrReadStore, AndOrWriteStore, complex query | Cc: | [email protected]… |
Blocked By: | Blocking: |
Description (last modified by )
The attached AndOrReadStore?.js and AndOrWriteStore?.js are identical to ItemFileReadStore? and ItemFileWriteStore?, except the read store's _fetchItems, filter function supports complex queries against the store.
Example queries supported:
Programmatic: query[:|=]"NOT id:23* AND (type:'test*' OR dept:'bob') && !filed:true" Widget (where json object may be required for query): query[:|=]{complexQuery:"NOT id:23* AND (type:'test*' OR dept:'bob') && !filed:true"}
Available logical operators (case insensitive):
, NOT AND OR ( ) ! && || Note: "," included for legacy queries (translated to AND).
Also, simple queries, as typically used with the other stores, are supported.
The stores are intended for dojox/data.
The attached AndOrXXXXStore.js unit test files are intended for dojox/data/tests/stores. The test file names are temporarily pre-fixed with "t" to prevent overwriting.
The attached patch file adds the two stores to the modules.js file in dojox/data/tests.
Attachments (6)
Change History (18)
Changed 14 years ago by
Attachment: | AndOrReadStore.js added |
---|
Changed 14 years ago by
Attachment: | AndOrWriteStore.js added |
---|
AndOrWriteStore?.js, complex query capability
Changed 14 years ago by
Attachment: | tAndOrReadStore.js added |
---|
to be renamed to AndOrReadStore?.js and placed in dojox/data/tests/stores
Changed 14 years ago by
Attachment: | tAndOrWriteStore.js added |
---|
to be renamed to AndOrWriteStore?.js and placed in dojox/data/tests/stores
Changed 14 years ago by
Attachment: | module.js.patch added |
---|
patch to dojox/data/tests/module.js to add the two stores
comment:1 Changed 14 years ago by
Summary: | AndOrReadStore, AndOrWriteStore: New stores supporting complex queries → AndOrReadStore, AndOrWriteStore: [cla]New stores supporting complex queries |
---|
comment:2 Changed 14 years ago by
Milestone: | → 1.1 |
---|---|
Summary: | AndOrReadStore, AndOrWriteStore: [cla]New stores supporting complex queries → [patch][cla] AndOrReadStore, AndOrWriteStore: New stores supporting complex queries |
comment:3 Changed 14 years ago by
Is the read store doing the filtering on the client side? So its first loading the data from the server and later filtering it in the browser?
comment:4 Changed 14 years ago by
Yes. The two stores are copies of ItemFileXXXXStore, with the only change being the query (_fetchItem) modified to accept a more complex query.
So, to do filtering for a Grid, you just do grid.model.query="...." and then grid.model.refresh(), and the Grid will reflect the results of the complexQuery.
comment:5 Changed 14 years ago by
Aha, so you could also extend the ItemFileXXXXStore and add a method such as _filterResponse() just like it was added to QueryReadStore? and supply a mixin or alike that supplies the filtering stuff you are suggesting? see http://trac.dojotoolkit.org/browser/dojox/trunk/data/QueryReadStore.js?rev=11711#L363 What do you think?
comment:6 Changed 14 years ago by
I didn't study that closely, but it seems possible, maybe for any of the stores? Are you suggesting that approach (1) to replace what I submitted or (2) using the complex query part from it for other stores? Both sound interesting...
comment:7 Changed 14 years ago by
I think it would also prove extensibility of the existing stores quite well if you could provide AndOrReadStore? as an extension, so I think it would be 1) of your options.
I have to possible ways in mind A) A new store extending ItemFileReadStore?
dojo.declare("dojox.data.AndOrReadStore", "dojo.data.ItemFileReadStore", { _filterResponse:function(data) { } });
Which has the big disadvantage of working ONLY with ItemFileReadStore? ...
B) Write a mixin that can be used for any store
dojo.declare("dojox.data._AndOrReadMixin", null, { _filterResponse:function(data) { } });
Which then can be used by the anyone to extend any store, i.e.
var s = new dojox.data.QueryReadStore(params); dojo.mixin(s, dojox.data._AndOrReadMixin);
And now "s" would also have the capabilities you suggested! Disadvantage is that one would always have to mix-in the _AndOrReadMixin. or is there something like
<div dojoType="dojox.data.QueryReadStore" mixin="dojox.data._AndOrReadMixin" />
I hope others have opinions too to know which makes most sense. Actually I like the second one best. But it might also very much be possible that I make things too complicated again :-)
comment:8 Changed 14 years ago by
Thanks. I like your suggestion of having a bite-sized piece of code to maintain and just being able to mixin it, with possibly having a pre-mixedin store, also, for the newer dojo users who don't yet grasp it, just want to grab a store and go.
I'll look at it some at the end of the week, unless you get there first :).
comment:9 Changed 14 years ago by
I vote generic mixin (b) so it can be reused in any store, in generic ways (if it's really that easy)
But this discussion should be continued on dojo-interest/contributors or more ideally the dojox dev forums.
comment:10 Changed 14 years ago by
Milestone: | 1.1 → 1.2 |
---|
A mixin helper (much like the stuff in dojo.data.util), would be nice for those who want to extend their query support beyond the recommended basic queries that all stores should support.
I'm going to move this to 1.2 so we can settle on how to put it in.
Changed 14 years ago by
Attachment: | dojox.data.AndOrStore_20080508.patch.zip added |
---|
Zipped version of the patch. Otherwise too big.
comment:11 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 Changed 11 years ago by
Description: | modified (diff) |
---|
Incase tihs is a better way to ping previous devs about this -- copying my email to dojo-contribs here
Would anyone know why these don't extend ItemFile*Store's? Over the years IFR/WS have received updates that never made it into these and had they not been copy/paste files they would have received most of these upgrades as well? Not looking to validate individual tickets or anything, just trying to make sure I didnt miss something obvious as I troubleshoot some issues with AndOr stores...
AndOrReadStore?.js, complex query capability