Custom Query (18300 matches)

I think it would be helpful that dojo/store provides an implementation of a query engine allowing (optionally) to recurse into the children of items, such that hierarchical data can be queried. This could be either an option of the default engine (store/util/SimpleQueryEngine) (say, similar to the deep:true option of dojo/data), or it could be implemented in a new, distinct engine.

As a bonus, it would be nice that dojo/store provides an in-memory store that implements the getChildren() method. (A related ticket: #13781.)

Adding such features would help people to replace the usage of the old dojo/data stores by dojo/store without loosing features and without forcing them to convert hierarchical data into flat data.

Since the introduction of ios6 full-screen support (#16066), dojox/mobile/common listens to global "resize" events on ios6 and performs a "resizeAll" in order to adjust the display. Heuristics are used to determine whether the "resize" event is likely to be due to the user switching on/off the new iOS6 full-screen mode. These heuristics help skipping most, but not all the resize events which don't correspond to switching on/off the full-screen mode. In most apps, these "false positive" resize events are harmless, but they have been found to be harmful in some cases (for instance when they indirectly trigger a page scroll, due to the address bar hidding). Hence, the heuristics have been enriched to cover more particular cases (#16361, #16202). But... yet another harmful case has been found:

How to reproduce:

1. Launch demos/mobileGauges/demo-iphone.html under ios6
2. Go to any gauge.
3. Back
4. Go to a second gauge (any other), scroll to bottom enough to produce a "bounce back" (no need to touch a gauge)
5. Back
6. Go to the first gauge

==> KO: the gauge view is empty

And a second failing scenario, still with dojox/dgauges:

1. Launch demos/mobileGauges/demo-iphone.html under ios6 in portrait orientation.
2. Go to any gauge.
3. Turn back and forth between portrait and landscape orientations.

=> After some (variable) number of orientation changes, you get either the header, or the gauge, or both not centered anymore. (Workaround: turn the device again.)

Both cases appear to be side-effects of the extra calls of common.resizeAll(). The resizeAll ends with calls of resize() on the gauges at bad moments... (when their marginBox is empty).

To avoid these troubles and others that might be discovered in the future, a new, simpler and safer way to detect the full-screen switching has been implemented (see attached patch). This replaces all the previous heuristics (instead of adding to the existing ones). According to various tests it appears so far to be 100% reliable, that is dojox/mobile/common now calls common.resizeAll if and only if the full-screen is turned on/off.

The following are deficiencies on various browsers of the "close button" (button with a cross icon for clearing the text of the input field) of dojox/mobile/SearchBox:

How to reproduce:

Load ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/mobile/tests/test_FormControls.html (or any app containing a dojox/mobile/SearchBox), then:

a) iPhone 5 iOS 6.0.2 1. Touch the SearchBox => The virtual keyboard shows-up, and the close button too. So far so good. 2. Type some characters, then touch the close button. => KO: pressing the close button has no effect. 3. Touch "Done" to close the virtual keyboard. => KO: the close button still shows-up, while in native apps (iPhone's Contacts app) the close button only shows up when touching the input field and disappears when closing the virtual keyboard. Touching the close button when the virtual keyboard is closed doesn't clear the input field either.

b) iPhone 4 iOS 4.3.3 1. Touch the SearchBox and start typing characters => KO, the close button doesn't show up. 2. Touch "Done" to close the virtual keyboard. => KO: the close button now shows-up, and touching it clears the input field (the virtual keyboard also opens). But in native apps (iPhone's Contacts app), the close button only shows up when touching the input field and disappears when closing the virtual keyboard.

c) HTC One X Android 4.0.4 and Samsung Galaxy Tab 10.1 Android 3.1 (same behavior on both)

1. Touch the SearchBox and start typing characters

=> The close button is not visible (color mismatch?), however touching at its usual location does trigger a clear of the input field.

For completeness, here is how it goes on desktop browsers (which are less important than mobile browsers):

d) Desktop W7, Chrome 24

Works fine.

e) Desktop W7, Firefox 18

No close button (no compat support). Place holder ok.

f) Desktop W7, IE9

No close button and no place holder.