| 249 | | // In most implementations the query will probably be a string, but |
| 250 | | // in some implementations the query might be a Date, or a number, |
| 251 | | // or some complex keyword parameter object. The dojo.data.api.Read |
| 252 | | // API is completely agnostic about what the query actually is. |
| 253 | | // In general for query objects that accept strings as attribute value matches, |
| 254 | | // the store should support basic filtering capability, such as * (match any character) |
| 255 | | // and ? (match single character). |
| | 249 | // However, as of dojo 0.9, 1.0, and 1.1, all the provided datastores in dojo.data |
| | 250 | // and dojox.data support an object structure query, where the object is a set of |
| | 251 | // name/value parameters such as { attrFoo: valueBar, attrFoo1: valueBar1}. Most of the |
| | 252 | // dijit widgets, such as ComboBox assume this to be the case when working with a datastore |
| | 253 | // when they dynamically update the query. Therefore, for maximum compatibility with dijit |
| | 254 | // widgets the recommended query parameter is a key/value object. That does not mean that the |
| | 255 | // the datastore may not take alternative query forms, such as a simple string, a Date, a number, |
| | 256 | // or a mix of such. Ultimately, The dojo.data.api.Read API is agnostic about what the query |
| | 257 | // format. |
| | 258 | // Further note: In general for query objects that accept strings as attribute |
| | 259 | // value matches, the store should also support basic filtering capability, such as * |
| | 260 | // (match any character) and ? (match single character). An example query that is a query object |
| | 261 | // would be like: { attrFoo: "value*"}. Which generally means match all items where they have |
| | 262 | // an attribute named attrFoo, with a value that starts with 'value'. |
