Opened 10 years ago

Closed 10 years ago

#14889 closed enhancement (wontfix) Provide a loading/querying flag

Reported by: Paul Christopher Owned by: Kris Zyp
Priority: undecided Milestone: tbd
Component: Data Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:



A web page contains several FilteringSelects. Each FilteringSelect uses a different JSON REST Store. Everytime a request to the sever is performed, a loading hint should be unobstrusively displayed right next to the respective FilteringSelect. (A loading hint blocking the whole screen should not be used.)

Of course one can override FilteringSelect and figure out in hours of work, which of the methods to hook on so as to display this notification so that it works for both keyboard and mouse input.

It would be much easier if there were a boolean property called "loading" / "querying". One could do a watch like so'querying', function(){
  // Do something e.g. showing / hiding a loading hint

This would allow for loose coupling and quick enhancement. Having this flag at hand would be also helpful if there were further ajax activities on the page, activities, that need another loader, e.g. a loader that blocks the whole screen.

With the loading flag, you can only watch the specific ajax activity of a specific store.


This flag is especially useful for JSON REST stores, however it might be a good idea to provide this querying flag to all stores?

All in all, the documentation lacks an example of how to listen separately to different ajax activities and reacting on each of them in a specific way. Dojox.widget.loader gives an example of how to watch globally for ajax activities. But I don't know whether this still works in Dojo 1.7.2., since the source code is marked with a "FIXME" tag. I also don't know how to display different loaders at different parts of the screen using this approach.

Change History (4)

comment:1 Changed 10 years ago by bill

Each FilteringSelect uses a different JSON REST Store.

What if they point to the same store? Wouldn't it be more useful to have a querying flag on the FilteringSelect?

Last edited 10 years ago by bill (previous) (diff)

comment:2 Changed 10 years ago by Paul Christopher

If the flag resides within the store, every widget using some kind of store as storage backend would "inherit" this functionality. Then you could do something like this:'querying', function(){
  if(mywidget.isFocused) {
    // Show/ hide loader

Of course this is based on certain - indeed questionable - "assumptions" and might not work in all cases. But if the flag is only in the widget, you need to add this flag to all other widgets that might use a store (such as the grid widget for example). Most widget authors might also forget to include this flag in their widgets which might cause trouble to others trying to reuse the custom widget in their code.

But you are right: It does also make sense to put it directly into the FilteringSelect. Ideally - since we cannot foresee all cases of usage - the flag will be added to both: The FilteringSelect and the store base class?

comment:3 Changed 10 years ago by Paul Christopher

Cannot judge this: But will be using dojo/request/notify be a solution? seems to be a solution for a generic page wide "ajax activity" watcher...

comment:4 Changed 10 years ago by Kris Zyp

Resolution: wontfix
Status: newclosed

I believe you could also monitor the querying status in loosely coupled fashion by adding an around or after aspect to the query method:

    aspect.after(store, "query", function(results){
      // show loading status
         // hide loading status
      return results;
Note: See TracTickets for help on using tickets.