Enable AJAX self-refreshing views

Revised patch that addresses the first and third issues I noted above.

1. When issuing an ajax request for paging or table sorting, cache the request data in the Drupal.settings object. When refreshing, use these cached data if available; otherwise, default to the view's original data.

3. When issuing an ajax request for paging or table sorting, cancel any pending refresh operation.

These two fixes need further testing but seem to be working.

I'd prefer to have #277321: AJAX links not supported for summary views in attachments completed and applied before completing this issue, as #277321 includes cleanup of the existing ajax javascript code that will make this new patch a bit cleaner.

Still to come, visual cues on the updates. Doing this will require adding data to each item in the view. E.g., for table views, we will need something like:

That will allow comparison of old and new items. Also needed: pass the information that this is a refresh and thus should be displayed differently than the default of simply replacing the old view with the new.

Visual cues like fading out old and in new items would be good, but it looks like they would require some significant changes to the code. Currently theme functions don't receive data on what type of object is being themed (e.g., 'node', 'user') or the ID of the item being themed. For example, when rendering a list of nodes in table form with fields of node title and author, the table theme template receives an array of rows containing the fields to be rendered but no data on what object type is being rendered or the nid values corresponding to the rows.

So maybe we should save visual cues for a follow-up patch?

When testing this with the default glossary view, I sometimes get the Javascript alert "An error occurred at ...." immediately after clicking a link. What may be happening is that an update is in progress. The AJAX response arrives but the page is already in the process of unloading.

On the glossary view, but not on the frontpage one, I also get a Javascript error with every refresh:

this.parentNode is null

Possibly related to the attachment. Are both the attachment and the main node trying to refresh? I'll dig around a bit when I get a chance.

I've read up on this but I don't have any concrete suggestions for what to do about the errors we're seeing. The dependency you've created is committed, though, so there is room for this to proceed.

It is not high on my priority list, though it could be a nifty feature.

Hello Nedjo, I applied the patch as you suggested. In terms of functionality, its 80% there with a few minor issues (most of which you already seem to have observed yourself)

1. I also observed the issue in #3 and logically, the explanation you gave seems the most likely one
2. It breaks down the other AJAX features like pagination that I am using. Again, similar to issue 1 that you've said in the patch description
3. I set the timer to refresh in 1 sec but I believe in my case, the images attached to the view (12 of them) also refresh. It is taking a good 2-2.5 seconds... What do u suggest as a turnaround for this issue? Can we omit a certain field from being refreshed?

Thanks a lot for your patch. Made my life extremely easy!
Ravdeep

Sorry to bump but can someone give me a lead on the 3rd point I raised above... How can (if we can) we refresh individual fields in a view at a pre-determined interval (say 1 sec - 5 sec)?

I tried out an approach of views caching but what seems correct logically that part x of a node is cached and part y of the node is refreshed periodically is not working out when I tried to implement... Any help is appreciated... Thanks!
Ravdeep

I've tried installing the patch but with no success, I tired doing it by hand but see a lot of differnces between the patch and the views code i have.

Here's a refreshed version of the patch, made on HEAD. (Is that right, or should it be the 6.3 branch?)

The changes are pretty simple. I've pulled the code for loading a view into a separate method so it can be used both for the existing calls, e.g., pager clicks, and for refreshing a view.

When we load a view via AJAX (exposed filter form submission, summary click, etc.), we cache the new data so it can be used in subsequent refreshes.

It's sorta working but I've only given it very rudimentary testing. Testing and reviews would be great.

Marking this so I can come back and test the patch in the next couple of days. I'll report back soon.

Thanks!

Testing suggestions:

On a variety of views, e.g., glossary, calendar, frontpage:
- edit the view, enable AJAX, and set a refresh interval, e.g., 5 seconds
- enable an exposed filter, if one is not already in place
- try the pagers, summary links, and exposed filters

Note that, except on a busy live site, the auto refreshing will be pretty much invisible. You can briefly see it in action if you hover your mouse over the view and watch the admin links; they briefly disappear during a refresh.

Another way would be to give a view a relatively long refresh rate, view it, in a separate window save changes to it, then return to see the effect. E.g., set a filter by content type (show page and blog), view the page, then in another window change the filter to story and blog. In the refresh, page content should disappear and story content appear.

Can a tar or zip download of the views.module file (Views 6.x-2.6) with the patch applied be made available so that it can be tested easily by those who are unable to apply the patch ?
Else can this be a separate small module, which when enabled, will give option to the Admin to enable ajax refresh of any Views list, be it table, list, grid whatever ? This will also have the advantage that it can be disabled if its found causing any problem within Views or having any clash with other already running ajax features in a site.

Thanks a lot for this great and essential feature.

It's not practical to post a full tarball for each patch. See the Drupal handbook thought for detailed instructions on how to get going with applying patches, http://drupal.org/node/60108. Or you can contact me via my contact page and I'll email you a patched version.

subscribing. totally want this.

I did take a quick look at this. It's going to take a longer look.

One thing I'm worried about is that in the effort to port to D7 and a similar but parallel effort to start using CTools (which, for the AJAX model is similar) I'm finding myself concerned by the code in ajax_view.js -- there's a lot of very similar code in there and sometimes the logic is a little hard to follow exactly what's going on and why. This patch adds even more to that. That's going to make this more difficult to port to D7/CTools.

Perhaps this patch should come about as a re-organization. Maybe what we should do, for now, is re-organize the AJAX so that we duplicate what CTools is using. Then, porting it to CTools/D7 will be much simpler? I realize that's a bit more work up front, but it'll save some big work at a big step a little later on.

Makes sense. I opened #591302: Rewrite ajax_view.js based on ctools AJAX and will have a look as soon as I find time. Meanwhile marking this postponed.

Two issues to jot down while I'm thinking of them.

1. I noticed that ajax_load broke with this patch. The issue is that we create a unique key (view_dom_id) for a view's data in Drupal.settings but this key differs by page load (it's a simple counter of the views we've rendered, and this can be different when we're reloading data through an AJAX call). When refreshing, we explicitly pass the domId for the existing content, which is fine if we're not merging in the new Drupal.settings data. But since ajax_load does merge in these new data, the references are incorrect.

Maybe we could solve this by making the view_dom_id [edit] reference e.g. the view name and display?

2. I opened a new issue, #591320: Mark views rows with unique ID, e.g., node-21.

I love fun stuff :) Subscribing. Thanks

This patch tottally rocks, but I am having issues using GMap display, first time is shown well, but when the first refresh comes, I get this error:

Javascript is required to view this map.

I will begin to look at this in the gmap module, but if you have some clues of what could be happening it will be really helpful

cool, I have to test it. That's what I was looking for, thx!

subscribe

subscribing - looking forward to help with testing when needed

subscribing.

sub

Would this be tied to the Exposed Filter Plugin in anyway or a separate issue?
Thanks

Completely unrelated. =)

hehe, thanks for the confirmation merlinofchaos =)

I think that's what i need i'll test it