With AJAX build in, it's a small additional step to enable optional automatic refreshing of views.

Here's an initial patch. More or less working, but needs refining.

1. We will need to track state information, so that the reloading reflects e.g. the current pager location or table sort. Started to put this into the patch but didn't get it working. Opened a separate related issue: #343535: Enable bookmarking of AJAX views.

2. Some effects here are probably called for. E.g., compare new display to old one, fade out items that are gone, fade in new ones.

3. Need to address collisions between different AJAX requests, e.g., automatic refresh while clicking a paging link. If one beats out the other, we'll get errors.

CommentFileSizeAuthor
#8 343542_8_views-refresh.patch14.01 KBnedjo
views-ajax-refresh.patch9.01 KBnedjo

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Title: Enable AJAX refreshing of views » 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:


<tr class="node-123">...</tr>

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.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs work » Needs review

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?

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs review » Needs work

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.

merlinofchaos’s picture

merlinofchaos commented

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.

ravdeepchawla’s picture

ravdeepchawla commented

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

ravdeepchawla’s picture

ravdeepchawla commented

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

arbel’s picture

arbel commented

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.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs work » Needs review
StatusFileSize
new 343542_8_views-refresh.patch14.01 KB

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.

peterjmag’s picture

peterjmag commented

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

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

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.

kaakuu’s picture

kaakuu commented

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.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

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.

drewish’s picture

drewish commented

subscribing. totally want this.

merlinofchaos’s picture

merlinofchaos commented

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.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Needs review » Postponed

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.

gausarts’s picture

gausarts commented

I love fun stuff :) Subscribing. Thanks

pcambra’s picture

pcambra
he/him
Primary language Spanish
commented

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

nchase’s picture

nchase commented

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

aren cambre’s picture

aren cambre commented

subscribe

Bilmar’s picture

Bilmar commented

subscribing - looking forward to help with testing when needed

pribeh’s picture

pribeh commented

subscribing.

benone’s picture

benone commented

sub

Bilmar’s picture

Bilmar commented

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

merlinofchaos’s picture

merlinofchaos commented

Completely unrelated. =)

Bilmar’s picture

Bilmar commented

hehe, thanks for the confirmation merlinofchaos =)

youkho’s picture

youkho commented

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

mmilo’s picture

mmilo commented

Subscribing!

OliverColeman’s picture

OliverColeman commented

sub

pheraph’s picture

pheraph commented

Did anyone succeed to use patch #8 with Views 2.8? Fails here in some cases.

YK85’s picture

YK85 commented

+1 subscribing

pribeh’s picture

pribeh commented

subscribing

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Version: 6.x-2.x-dev » 7.x-3.x-dev
Status: Postponed » Active

I think the way forward is to implement this first for Views 3 for D7. Then, potentially, it can be backported as part of #591302: Rewrite ajax_view.js based on ctools AJAX.

dawehner’s picture

dawehner
Primary language German
commented

Mh.

Currently the development workflow is that the patch is created for drupal6-2and3.x and the get ported to 7.x. But if its easier to implement in d7 do it there first :)

AdrianB’s picture

AdrianB commented

Subscribing.

vaartio’s picture

vaartio commented

Subscribing

dawehner’s picture

dawehner
Primary language German
commented
Version: 7.x-3.x-dev » 6.x-3.x-dev

I still think this should be developed first for d6

pribeh’s picture

pribeh commented

Bump for D6.

xamount’s picture

xamount
Primary language English
commented

+1 subscribing

Isostar’s picture

Isostar commented

+1 subscribing

XiaN Vizjereij’s picture

XiaN Vizjereij commented

Subscribing

rburgundy’s picture

rburgundy commented

subscribing

infojunkie’s picture

infojunkie
Location Vancouver
commented

subscribing

Remon’s picture

Remon commented

+1

not_Dries_Buytaert’s picture

not_Dries_Buytaert commented
Title: Enable AJAX self-refreshing views » Enable optional auto-refreshing views using AJAX

+1 subscribing

A bit late, but maybe still useful for Views 2:
http://www.phinestsoftware.com/blogpost/2009/8/4/views-ajax-exposed-filt...

BenK’s picture

BenK commented

Subscribing... any more work being done on this?

XiaN Vizjereij’s picture

XiaN Vizjereij commented

I've found a workaround with http://drupal.org/project/block_refresh to ajax refresh views in blocks. Would be nice to see it in views itself thou.

dawehner’s picture

dawehner
Primary language German
commented

Personally i would mark this issue as postponed because noone worked on this for long time.

XiaN Vizjereij’s picture

XiaN Vizjereij commented

Just today an issue got committed to drupal core that was around since version 4.x ... so i would not count it out ;D

dawehner’s picture

dawehner
Primary language German
commented

It's not a problem as long someone does something :)

iamjon’s picture

iamjon commented
Status: Active » Postponed

The last patch for this issue was posted on august 2009. If someone would like to pick up from there it would be awesome.

http://drupal.org/node/343542#comment-1978766

Marking this as postponed.

SeanBannister’s picture

SeanBannister commented

Check out the Views Hacks module, if you download the dev version it contains Views Auto-refresh.

jelo’s picture

jelo commented

sub

merlinofchaos’s picture

merlinofchaos commented
Category: feature » task
Status: Postponed » Active

This feature is wanted a lot. Moving to active task.

bmx269’s picture

bmx269 commented

I too am wanting this for D7. I have a mobile sports score project that needs exactly this.

kenianbei’s picture

kenianbei commented

subscribe

steinmb’s picture

steinmb commented

+1 from me too. Does any code exist for Views 6.x.3.x or 7.x that we could start testing?

ocamp’s picture

ocamp commented

hi, is this included yet?

Bensbury’s picture

Bensbury commented

subscribe

mautumn’s picture

mautumn commented

+1 subscribing

ocamp’s picture

ocamp commented

views hacks in comment 51 worked for me

mautumn’s picture

mautumn commented

Yes. I'm using that as an interim solution. However, I'd prefer to use the features and interface of this module though...

infojunkie’s picture

infojunkie
Location Vancouver
commented

For what it's worth, here's a write-up on using Views Auto-Refresh mentioned above, including more advanced features.

mautumn’s picture

mautumn commented

Cheers for the write-up infojunkie. Some very useful features I didn't know about. I really appreciate your efforts.

mustanggb’s picture

mustanggb commented
Issue summary: View changes
Status: Active » Closed (won't fix)