Attached patch implements AJAX loading for views exposed filters.

When users submit an exposed filter, the content is new view is loaded through AJAX. The view is modified to return only the view portion (not the header or the exposed filter, which will already be on the page).

If a view has a pager, clicking the pager links also loads via AJAX.

I did only very basic testing. Needs testing in different situations. Issues will arise when loading views that require onload javascript events. Maybe, if there's interest in this behaviour, it should be a setting for an exposed filters as not all filters will work properly in javascript.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nedjo’s picture

Forgot to mention, this depends on a function in my Javascript Tools module so will only work if jstools.module is enabled. The function it uses, though, is not large and could be copied into the activeviews.js file to avoid this dependency.

moshe weitzman’s picture

subscribing. sounds pretty neat.

lilou’s picture

subscribe.

appel’s picture

Subscribing!

nedjo’s picture

FileSize
5.57 KB

Here's an improved patch, mainly tweaks to the js. I've added a drupal_add_js() call I'd missed for progress.js.

Patch is on the 5.x dev branch of Views but applies also to HEAD. Use with the 5.x dev version of jstools, http://drupal.org/node/113162.

I've put up a demo at http://islandnet.com/~nedjo/nicaragua/. To try the pager, select all three content types and scroll to the bottom of the page.

Tobias Maier’s picture

wohoo nedjo, this is more than great!

I tried your test site
what I think is missing is some message if there was no result found.
In views we can define a message, which gets shown if we don't have any result. Does your patch send this to the client in this specific case?

nedjo’s picture

I just hadn't defined a message. It appears now. To trigger it on the demo, you can select "Is None Of" and select all three content types.

This approach could easily be extended to enable loading of views in place, e.g., click on a link and the link is replaced by the view, or the view is loaded into a designated page element.

The main remaining work here looks to be handling cases where javascript errors will occur on ajax-loaded views, e.g., gmap views. This is part of a more general issue--how do we reattach behaviours to AJAX-loaded content? How should we handle that? Do we want to add a setting to each view to enable/disable loading by ajax? A drawback is that that would depend on user knowledge and trial and error.

nedjo’s picture

Status: Needs review » Needs work

Two things bother me about the approach I've sketched in.

1. In general, I like to see the ability to invoke existing methods for AJAX, rather than the methods themselves having to say 'is this AJAX'? So, in that sense, adding an internal test as I've done in views_view_page() seems a bit clunky.

2. I don't like introducing extra logic into theme functions, so, similarly, my 'is this AJAX' test in theme_views_view() seems suboptimal.

I'm going to have a crack at implementing this in a contrib module - dynamicload, part of jstools - to see if this can be implemented cleanly without patching views. At the least, this will provide a basis for comparison.

mfredrickson’s picture

I just submitted a patch to refactor out the handling of exposed arguments, so that you can pass the values into views_build_view, instead of relying on the $_GET query string.

You might find it helpful in your work on this:

http://drupal.org/node/125973

lunas’s picture

This no longer works. When you hit submit, it loads your entire page in the main content area where it used to just show the results. As such it looks like there are two versions of the site on the page, one cramped into the main content area and the outside one. You can see it on your demo site listed above as well. Any idea why? I liked this functionality and it worked until I updated a number of modules today. Jstools was one of them - not sure if that had an impact. Views was not upgraded.

markhope’s picture

subscribing - demo looks interesting!

JamesHayton’s picture

Subscribing

bcn’s picture

tracking...

csc4’s picture

subscribing

mrgoltra’s picture

subs-track

Wim Leers’s picture

Subscribing.

momper’s picture

Subscribing

Anonymous’s picture

Tracking.

I was able to add and run a successful test on Drupal 5.1. However, the pagers didn't work quite right.

Prodigy’s picture

What about loading sorts through ajax? Same logic? What would be different?

nedjo’s picture

The Dynamic Views module looks to include this functionality, http://drupal.org/project/dynamic_views.

Wim Leers’s picture

@nedjo: not quite. It completely change the exposed filters (makes an ul out of every exposed filter, each choice of the exposed filter becomes a li), which is not desired at many places.

.-_-.’s picture

Status: Needs work » Needs review

i have tried this technique [patch] and also AjaxSubmit in the jstools modules pack [are they the same?] and for me both produce the same error as mentioned in #10 , the header, filters and potential results are repeated in the body with no results, very wierd, so at the moment i can't find a working way of submitting a form " a views page with exposed filters and submit button" using ajax, i really need to be able to produce the results with out refreshing the filters part of the page.
any other leads to get Ajax to submit a views form?
will also mention this in jstools issue queue.

rickvug’s picture

subscribing

palik’s picture

subscribing - very interesting and cool feature :)

baja_tz’s picture

subscribing

gellpak’s picture

Subscribe

merlinofchaos’s picture

Would anybody be interested in working on this for Views 2?

In general I have the ajax tools necessary to do it; but there are several challenges:

1) exposed filters may not always appear with the view. Therefore there needs to be some way to activate this.
2) We need a callback which includes all of the information necessary to recreate the view. That means the view name, the display ID and the arguments that were used to form it.

Hm. I guess that's all I can think of.

nedjo’s picture

Status: Needs review » Active

I'm in. I'll need to study the Views 2 code to begin to understand what's needed. Maybe we could connect and you could give me a quick primer on what's in place and what more is needed.

merlinofchaos’s picture

I'd love to. Look me up on IRC; you know where I'll be =)

nedjo’s picture

Status: Active » Needs review
FileSize
4.72 KB

Here's a basic patch to get this rolling.

Earl and I discussed the problem and concluded we don't need special handling for exposed filters, but rather a generic way to load a view, any view, via AJAX.

Details of the patch:

* Introduce new .js file, ajaxView.js, with simple method for loading views via AJAX. Add behavior that attaches to exposed filters. Maybe this file should actually be ajax.js and the existing ajax.js be renamed e.g. ajaxAdmin.js, for use only on admin (views_ui) pages.
* Minor changes to existing .js files, e.g., need to test for UI tabs plugin before calling its method.
* Introduce test into views_page() to see if we're loading via AJAX and respond accordingly.

This last point is the one that needs the most examination. Maybe we actually need a new callback just for AJAX view requests. To determine whether this is an AJAX request I used a header sent by jQuery--one of many ways we could do this.

There's lots that we could look at adding here, e.g., visual cues about the request status, but let's look first at the basic implementation. What's good about the appoach? What needs changing?

merlinofchaos’s picture

I definitely feel we need a specific callback for ajax; otherwise, we're limiting this feature to just views with the 'page' display, but this would be very very useful for block displays. In fact, I could then relax the restrictions on the block pager. We could then update the use_pager setting from 'yes/no' to 'no/simple/ajax', and then the 'block' display can remove 'simple' from the list of choices. And it can turn on exposed filters; and we can turn on the exposed filter settings to do similar. That's probably phase 2 or 3, of course. We will also want a similar setting in the 'table' style for clicksorting.

For the same reason, we can't use $view->execute_display() -- because that returns data that is specific to that display type. For page, it works out just fine because that just returns raw html, but $block returns an array with 'subject' and 'content' which obviously won't display properly in this situation. ->preview(), however, will always just return HTML. Also, ->execute_display() will also try to do the other things specific to that type of display; for example, setting the breadcrumb, setting the page title, etc. These things should not be performed on an AJAX callback.

I'm ok with renaming the existing ajax.js to admin_ajax.js -- but for my filenames I'm sticking with underscores, not camelcase. We can then use ajax.js for this functionality. That is sensible.

Overall I'm happy with this direction. Thank you very much for working on this; I think it will be an awesome feature and people will really love what it gives them.

moshe weitzman’s picture

Looks reasonable to me. Perhaps you could add URL where someone like me could learn more regarding this comment "// See if we have any settings to extend. Do this first so that behaviors can access the new settings easily."

If we wanted to research a bit more, the Services module already will provide a View in JSON and other formats. Maybe a chance to unify some code here.

nedjo’s picture

FileSize
7.56 KB

Okay, here's a new patch.

We use an AJAX-specific callback, controlling access through the regular test for $view->access. Is this right?

We need a way to determine, from within the view output, the view name and display_id. We could pass these in Drupal.settings, but that in itself doesn't help us link the data with the content on the page. Instead I've added two classes, view-name-viewname and view-display-id-displayid, where viewname is the view name and displayid the display id. We can't reuse the existing view-viewname class because it's converted for CSS use (underscores replaced with dashes). This code could probably be done more efficiently. It shd also be in a distinct method, as - if we take this approach - we're going to need to determine the name and display in all cases where we're ajax-processing a view, e.g., for handling paging links.

I haven't changed the file names (ajax.js to ajax_admin.js) because it made the patch too hard to read.

Things I don't yet understand:

1. How can we pass arguments to the view? I guess we could pass these in as a request variable?

$args = $_REQUEST['args'];

2. How can we handle $_GET['q'] for paging? See // TODO comment in views_ajax() in views.module. We could reset $_GET['q'], but how do we know what it's supposed to be?

3. How do we determine the display_id of the view to pass it to the theming layer? See // TODO comment in theme/theme.inc.

Once we have these questions straightened out, we could look at handling paging links--it shd be relatively easy to point them to the same handler.

nedjo’s picture

FileSize
9.97 KB

Here's a fuller version of the patch, addressing the problem of how to load dependent data along with content (which is what the settings data handling Moshe referred to is for).

Whenever we're loading new content via AJAX, there is the potential that the content may need any of four supporting data pieces:

* css files that weren't loaded in the original page load
* js files that weren't loaded in the original page load
* new js settings data
* inline scripts

For example, a view might not show a particular piece of content (a map) the first time it's loaded, but after filtering this piece of content is shown, and its display requires a css file, a .js file and associated behaviors, and data passed to the Drupal.settings object.

New in this version of the patch (and not fully tested):

1. views_ajax_data() in views.module, assembles JS and CSS data for return with the JSON object.
2. Drupal.Views.Ajax.loadFiles and Drupal.Views.Ajax.loadComplete in ajax_views.js, merges in new settings data and loads any new JS and CSS files.

Along with the content, data are passed to the browser indicating the JS and CSS files and the JS settings data to be loaded.

I think the JS loading will break under JS aggregation, because of the possibility that existing methods are overwritten when new aggregated versions of the same files are pulled in. Not sure what to do about this.... Maybe we have to turn off the whole AJAX view loading JS is enabled.

This version of the patch introduces additional complexity and would some focused testing. I think it's needed, though, if we're going to be loading content that we don't know the associated data needs of in advance. The alternative, I guess, would be to provide a UI selector for admins to be able to turn AJAX loading off for a particular view if they tested and found it broke, but that seems like a poor fallback.

merlinofchaos’s picture

Just a quick update: The correct display ID will be in $view->current_display so that's easy to acquire.

I'm a little concerned about the complexity required to add a bunch of new js and css later. I realize that it's something that can happen, but it seems to me to be a relatively rare operation.

1) ajax loading won't be required on views, it will be strictly optional
2) something viewed via node_load is much more likely to use additional js/css than something that's just fields

It seems like we might be adding complexity to prepare for an edge case that we just don't have to. If there's a problem, we can always instruct them to turn off the ajax paging and use regular paging.

I do have a method of getting additional Drupal.settings into the system already, but it's not terribly robust. In fact, it's the lack of robustness in that system that has me worried that we might cause more harm than good with this; doing new javascript in an ajax load is very tricky.

nedjo’s picture

Yes, it would be easier to leave out the complexities of loading the JS and CSS data. I'll work on a new patch without this. The problem of loading associated data is a general one anyway and maybe belongs in its own module.

Here's a possible approach. We pass the AJAX response data through drupal_alter() before returning it to the client:


  drupal_alter('ajax_data', $object);

An external module could return data on required JS and CSS and also specify a JS callback for these data to be sent to. What do you think?

Forgot to mention that in the latest version of the patch I introduced path handling. We pass the page's path in the settings array then pass that back as part of the AJAX request and set $_GET['q'] to the path. I'm vaguely thinking that may help with paging of results. There's the related question of feeding path-based arguments to the view. Do we need to extract these and explicitly send them to the $view->preview call, or will they just be recognized from the $_GET['q'] value?

nedjo’s picture

Here are two new versions.

In the first patch, views-ajax-plain.patch, we simply strip out the JS and CSS handling.

In the second, we strip it out but pass the AJAX data through drupal_alter() before sending it to the client. As well as data on CSS and JS files and settings, modules implementing hook_ajax_data_alter() can specify one or more JavaScript callbacks to be called and fed the resulting data object. I've attached a draft ajax_load module that implements the hook. The idea is that we don't implement any special JS/CSS handling in Views but leave this open for other modules.

Both patches now read in the display ID from $view->current_display.

merlinofchaos’s picture

Looks like the only real problem we have left here is that $_GET['q'] isn't enough to get the arguments for the view. They need to be passed into $view->preview() as an array in the 2nd argument.

We've got 2 choices:

1) We can store the arguments somewhere on generate to make it easy to for the js to find them and pass them through
2) We can try to parse them out of the path.

I don't like 2. Not all views even have a path; but they may still have arguments.

I believe I'm in favor of the _alter hook. alter hooks are good in general, and this keeps the door open for doing extra stuff.

nedjo’s picture

Thanks for the further review.

For passing the args, I agree that passing them to the client to be passed with the AJAX request seems to be the better option. I guess we need to send them in the Drupal.settings data. I'll look for the right place to do so. In other places IIRC settings data are passed for a single view (since, in admin, only one view is being handled at a time). Here, I assume, we'll need multiple views (since more than one can be displayed on a page) identified by a combination of view name and display_id.

As the patch stands, AJAX loading for exposed filters isn't optional--it applies to all exposed filters. To make it optional for specific views, we would need to add a view setting? If so, I guess we should think ahead to other AJAX loading, particularly paging. Do we want a "load this exposed filter through AJAX" setting, or is what we want a more general "load this view via AJAX" setting that would apply to exposed filters, paging links, and whatever else? Earl, any direction on where such a setting would go and how to store it?

I may have a go at the paging links in the next version of this patch. I'm assuming the following desired behavior:

* A given page has several views in e.g. panels, each with paging links
* When a paging link is clicked without JS present, a new page is loaded where, typically, the view is the main content and the next page of data are viewed.
* With JS, however, the next page of data are loaded directly into the existing view content (e.g., within a panel)

Does this sound right? Good idea to include paging, or should we just limit this patch to the initial use case of exposed filters?

[Eventually, I suppose, we may want a different kind of AJAX loading behavior, one in which new records are appended to the existing ones. This would be e.g. for an image carousel, where it's desirable to be able to continue to browse previously-loaded images as well as new ones. But I assume that's beyond the scope of what we're trying to do in this issue.]

nedjo’s picture

FileSize
1.34 KB
15.23 KB

Here's a new patch. Main changes:

  • Added UI for designating whether a view should use AJAX. This is mostly working but has a bug. Earl, can you have a look?

    The new setting is use_ajax ("Use AJAX") in the "Basic settings" in view admin. I tried to follow the approach used for the use_pager setting.

    The UI appears to be working and the new setting is saved, but when viewing a view the new setting doesn't stick. For testing purposes I've temporarily overridden the setting so that the AJAX behavior will always be on:

       function pre_execute() {
    +    $this->view->set_use_ajax($this->use_ajax());
    +    // TODO: remove this.
    +    $this->view->set_use_ajax(1);
    
  • Implemented AJAX for paging links.
  • Data on each ajaxified view are sent to Drupal.settings. This includes the args, which are posted back to the AJAX callback.

I've used strings to pass an array of function callbacks and then in the AJAX callback passed them through eval(). It would be nice not to have to use eval, but due to limitations in drupal_to_js() I don't think we have a way of passing unquoted js function names.

I've attached an updated version of the demo ajax_load module, showing how the AJAX functionality can be extended.

I think this is getting close. Testing would be great. Some of the needed testing:

1. Create a view that includes paged results. Browse the view. Click on the pager. Do the correct pages load via AJAX?
2. Create a view that includes both an exposed filter and paged results. Browse the view. Submit the filter. Do the expected results load via AJAX? Now click the pager on the AJAX-loaded results. Working?
3. Create a view with arguments and paged results. Browse the view. Click the pager. Working?

moshe weitzman’s picture

Title: Load exposed filters through AJAX » Upon change in exposed filters, refresh node listing via AJAX
nedjo’s picture

FileSize
15.23 KB

Minor fix to JS issue (prevented paged links from working on initial page load).

ezra-g’s picture

Subscribing. Hope to test soon.

merlinofchaos’s picture

Status: Needs review » Fixed

Ok, I ran through this and did some testing. I found 1 bug that is worth noting for future reference:

When multiple views were on the screen, the ajax_path will turn into an array, with the actual path repeated once per view that is in the list. As near as I can tell, this is an affect of drupal_add_js and I don't see a way to stop it. So I added a check to the path in the .js to see if it's an array, and if it is to just use the first element. There's probably a cleaner way to do that; if you want to patch it, great.

I extended it to work on tablesorts.

I opened up blocks to use paging.

I added theme_views_mini_pager which is a cut down pager that just has next, previews, and Page X of Y on it. Turns out that was really easy to do; take theme_pager and...cut out most of the code. =)

and this is now committed!

merlinofchaos’s picture

Oh! I removed the hardcode that set use ajax to true. I think the reason you might've been having trouble with it is that existing views don't have the setting to use the default, so you may have been seeing your page views override the setting. IN any case, I simply removed the hard-set and it worked for me. Let me know if you still have problems with that.

merlinofchaos’s picture

Related issue; it was pointed out that we need some kind of visual feedback. So here's an issue for a throbber: http://drupal.org/node/239911

nedjo’s picture

Status: Fixed » Needs review
FileSize
697 bytes

Thanks for reviewing and improving this, it's nice to see it go in!

I realized I'd left in a JS helper function that's now not used (since we went to the approach of passing data on the views in Drupal.settings). Attached patch removes this obsolete function.

Also, I think the issue with the ajax setting not sticking was that I was overriding the 'frontpage' default view. I suspect we need to add 'use_ajax' => true; to the exported view. I noticed that, when exporting a view, the 'use_ajax' property exports as a string ('0') rather than a boolean like use_pager. I couldn't immediately find where to fix this. So I think some further work is needed on these two areas: format of the use_ajax property and inclusion of use_ajax in default views.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed. Thanks! And thanks *very* much for the hard work on this patch!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

nrasmus’s picture

I'm sorry if this is not the place to post this: I'm very interested in being able to display exposed filter results in the same panels 2 pane as the original view. I've set the panel to make the view's URL the same as the panel, and that allows the pager to work just fine, but using my exposed filter loads the default page view of the view.

I may be missing something simple, but this patch seems to promise this capability (with AJAX). I'd be fine with a non-AJAX solution to this, but this would be great. Is it currently possible to get it working on 5.x? I tried patching with the patch supplied in #5, but the first hunk failed.

merlinofchaos’s picture

This is a Drupal 6 feature only; it won't work at all with Drupal 5. Sorry.

nedjo’s picture

Views 6.x will include this functionality in a form completely different from the early 5.x patch. There are no plans that I know of to backport to 5.x.

Sean-Khan’s picture

Status: Closed (fixed) » Closed (won't fix)

Hello,
I take it that views code has changed a lot recently, I get a bunch of errors when trying to use patch. I really need this kind of feature, has /could anyone make it work for latest version of views?

Thanks!

ezra-g’s picture

Status: Closed (won't fix) » Closed (fixed)

This functionality is already in the latest version of views. No need to apply the patch.

Sean-Khan’s picture

Oh, so I read it wrong...

What I'm looking for is a view that would update after changing filters without user clicking 'Apply'. If someone's done such a fix I'd appreciate if I'd be pointed to right direction - or if someone actually could do such or tell how to do such a mechanic! I'm not familiar with ajax mechanics, I tried submit with onChange but it just sent the form instead.

Thanks!

Anonymous’s picture

I agree with #55, one should not have to click the 'Apply' button as it almost defeats the purpose of using ajax for the exposed filters. Forgive my programming ignorance, but what are the implications for removing the button? Can it be done?

DrupalNovice’s picture

Hi!
Yes, you can hide the 'Apply'-button and make the exposed filters auto-submit when you select a value in the list, check a checkbox, or something similar.
I use the exposed filters with the Better Select module (converts select elements to checkboxes) to allow users to choose between calendars.
This method should work if you have Drupal 6.x and Views 2.x installed. It relies on hacking the Views module a bit - or the ajax-views.js file in the views/js directory to be more precise.

The solution:
1. You have to have AJAX enabled for the View in order for this to work, so if you haven't enabled it already, go and do so now.
2. Go and open up the file ajax-views.js in the [modules]/views/js directory, and follow along.
3. At the top of the document, but below Drupal.Views.Ajax = Drupal.Views.Ajax || {};, add this code:

$(document).ready(function() {
  // If you wan't to hide the 'Apply'-button, you need to do it here...
  $("form#views-exposed-form-name-of-my-view #edit-submit").hide();
});

4. Now, a few lines down, change this:

if (response.status && response.display) {
  var $newView = $(response.display);
  $view.replaceWith($newView);
  $view = $newView;
  Drupal.attachBehaviors($view.parent());
}

...to this:

if (response.status && response.display) {
  var $newView = $(response.display);
  $view.replaceWith($newView);
  $view = $newView;
  // ... but you also need to do it here!
  $("form#views-exposed-form-name-of-my-view #edit-submit").hide();
  Drupal.attachBehaviors($view.parent());
}

5. Just below Drupal.behaviors.ViewsAjaxView = function() { , add the following code:

  // Run the forms submit function when a checkbox has been checked/unchecked
  // [if you don't use Better Select, use "form#views-exposed-form-name-of-my-view select" as selector instead]
  $("form#views-exposed-form-name-of-my-view .form-checkbox").change(function() {
    // [Only apply if you have Better Select installed] 
    // Since we're using AJAX and the amount data that's being loaded can differ a bit, 
    // we're going to give the user some feedback. This will add a gif loader right 
    // after the label of the checked fitler-item (if you have Better Select installed)
    $(this).parent().after('<span class="views-throbbing">&nbsp</span>');
    // Execute the submit function on the form
    $("form#views-exposed-form-name-of-my-view").submit();
  });

6. [Only apply if you have Better Select installed] Two last steps - locate $('input[@type=submit]', this).after('<span class="views-throbbing">&nbsp</span>');, and comment it out.
The filtering process will take much longer if this load-gif-image appear.

7. [Only apply if you have Better Select installed] And last, locate /$('.views-throbbing', object).remove();, and comment that line out as well.

Go and test your View, and hopefully it'll work

The only problem I've noticed so far is when a user clicks multiple buttons at once - the checkboxes will delay in checking themselves after submit is completed. Maybe not an issue if you use a select-element instead of a checkbox element.

I'm not a fan of hacking modules, but when custom modules with hooks and theme layer modifications let you down, you have this one last friend to help you out.
However, if somebody else has a more Drupal-way of doing this, please let us know!

Credits to the authors of this page

Hope this will help all of you that struggle with this!

Christo

jdtart’s picture

This works great, does exactly what I want.

asak’s picture

Christo - this looks great!

I'm trying it out now... ;)

DrupalNovice’s picture

=D Nice to hear!

patcon’s picture

Helpful hints for #57:

1. In the two instances, use
$("form#views-exposed-form-name-of-my-view #edit-submit").parent().hide();
instead of
$("form#views-exposed-form-name-of-my-view #edit-submit").hide();

This will make it so that the little throbber circle doesn't appear beside where the APPLY button used to be.

2. Also, don't copy-paste the PHP tags themselves, because that would make you an idiot like me, and you might just waste an hour of your existence. Ugh. If you find nothing is AJAX-ified, but when you click apply once, the button disappears, then this is probably what you did :)

patcon’s picture

Anyone else finding that this doesn't work in google chrome? When you select another option for the filter (aside from the initial), everything (header and all) disappears.

http://biocomp.utoronto.ca/directory

But if you type in the filter by deep-linking, then it shows up fine...

http://biocomp.utoronto.ca/directory?rid=8

Anyone have any guesses as to what's causing this?

Also, as a sidenote, Firefox 3.0.10 works wonderfully, but IE 7.0.5730.13 has serious lag, and seems to freeze up for 20 seconds with each AJAX refresh.

SeanBannister’s picture

sub

patcon’s picture

It seems it was a problem with javascript handling in the older version of google chrome, and it's been fixed now.

acdtrp’s picture

I tried the solution in comment #57 and it works in Firefox, but not in IE7. Any ideas?

phinest123’s picture

There is no need to do all these changes to the views module files

You can just add your own behavior in your own module to hide the apply button as shown below.

Drupal.behaviors.modulename = function (context) {
  $("form#views-exposed-form-viewname-page-1 #edit-submit").hide();
  $("form#views-exposed-form-viewname-page-1 .form-text").change(function() {        
    // Execute the submit function on the form
    $("form#views-exposed-form-viewname-page-1").submit();
  });

heacu’s picture

sub

ezra-g’s picture

Title: Upon change in exposed filters, refresh node listing via AJAX » [Closed. Do not Subscribe] Upon change in exposed filters, refresh node listing via AJAX

This issue is closed and the feature is in Views. Please do not follow up on this issue. Open a new issue if you are having a problem.

Every time someone subscribes to this issue, a kitten dies.

simonswiss’s picture

In reply to #57

Hey Christo,

thanks for this precise tutorial.

I followed it but however nothing happened, i still dont get to enjoy the ajax autosubmit on my filter.. any idea why?

Do you need to replace each instance of "name-of-my-view" with the actual name of the view in the code? If so, how do i apply the ajax submit to multiple views?

Thanks for your help!

Simon

AdrianB’s picture

Just a quick question regarding #68:

This issue is closed and the feature is in Views.

In which version of Views? Is it in Views 2? Is it documented somewhere? (I searched but could only find threads like this one.)

(I don't think this question deserve a whole separate issue as ezra-g says in #68 - but if ezra-g thinks otherwise I'll open an issue.)

feuillet’s picture

This issue is closed and the feature is in Views.

Wher is it in Views?

patcon’s picture

I don't think it's in Views2, but it's in another module (albeit one I haven't actually tried yet):

Views Hacks module

Hopefully this helps! Correct me if the funcationality's different :)