AJAX links not supported for summary views in attachments

Can you please export and paste the view that is not working?

For some reason you have removed the formatting from the export. Please paste one that retains the formatting so I can actually read it. Thanks.

Currently, exposed fields don't display within blocks, since there's no way for blocks to really get the input. (It's dangerous to try to put responsive forms in blocks since they aren't pages themselves). There's probably a solution to this that involves using the link display, though, so I'll have to think about this.

In your export, your block display does not appear to be selected in the 'attach to' section of the attachment. Attachments must specifically state which displays they attach to, since complex views may not want attachments on all displays.

Currently, the AJAX updating does not support attachment displays.

Maybe!

I use attachments extensively in the Calendar, so I'm hoping this can get in :-)

I'm not clear on the exact issue.

To test, I created a new view, assigned it a page, assigned an argument (node type), and created an attachment to the page view. When browsing the view page, the attachment displays and is included in the AJAX refresh via pager links, both in summary and regular display.

So attachments seem to work via AJAX.

Is there a case where we have links in the attachment itself? I don't think paging applies to attachments.

Where I have the block, I have some $content just above the block,

Not clear what this $content is. A header to the view? Probably not, because I can't find a problem with headers--they are loaded as expected via AJAX.

Nedjo: Try the built in glossary view, which is provides argument links that change the view itself.

Okay, I see now.

We need to do three things to get links on summary views to load via AJAX, two easy and one hardish.

1. Add class selectors so we can attach behaviours to the links in summary views.

2. Extend the js so it recognizes the new selectors. Here we can simplify what's currently in the code, since there's a block of code that's repeated.

3. The main issue though is that currently we're passing in the Drupal.settings object a fixed idea of what the view path and arguments are--and these now need to change. We need to be passing a new path and new arguments. So we need to modify the construction of the viewData object that's fed with the AJAX call so it has the correct path and arguments. Offhand I suspect we need to:

a. modify the view path data that is sent to Drupal.settings so that it is the base path of the view without arguments.
b. write an equivalent to Views.parseQueryString() to parse the new view path and arguments--determine what part of the path is the view's base path, assume further arguments should be fed as views arguments
c. use $.extend() (IIRC) to merge the new data in. That is, the new method should come after we merge in data from the settings array, so those data are overridden.

Attached is a patch with some preliminary work for points 1 and 2.

Ok, this makes sense. What does not make sense is that the patch removes the ajax call?

When the table header processing was added, the AJAX call code was repeated. I've just merged the table header selector and the new summary selector with the pager links to avoid repeating this code. The AJAX call is still there, below the deleted (extra) one.

Here's a fuller patch that seems to be working, though it could use some looking over and maybe more documentation.

I don't know all that much about summaries and when and where they are displayed. Do we need to add a selector to views-view-summary.tpl.php?

I took the approach outlined in comment #14. It's a bit complicated by the need to parse a path out of the href attribute whether or not clean urls are enabled, which we have to do by (a) stripping off the protocol (IE returns the absolute HREF), (b) stripping off the base path, (c) stripping off the '?q=', if present. I added some methods for that, cribbed from jstools.js.

This should make for a more flexible method that makes it easy to add AJAX loading to further views links.

Nedjo: I don't have time to go over this patch right now, but to answer your basic question, summary views are displayed in the absence of an argument.

For example, I have a view 'archive' and it expects two arguments: year, month

'archive' --> displays a summary of available arguments for 'year'.
'archive/2008' --> displays a summary of available arguments for 'month'
'archive/2008/12' --> Displays whatever the view is for december, 2008.

Thanks for the explanation.

What I was wondering was whether we want AJAX-loading for all summary view links or if there are some links that need a full page refresh. That is, are all links to views or are some to e.g. nodes? The answer looks like, they'll all be to views and so AJAX loading should apply.

So here's a minor update to the patch that adds the class="views-summary" selector to the views-view-summary.tpl.php template and modifies the jQuery selecting to get this as well as the other summary items.

One of the changes I've made here is to pass a view_base_path property, which is read from the page view's path. This property is used to determine what are arguments to the view. If the base path is 'archive', a link to 'archive/2008/12' will be interpreted as arguments of 2008 and 12 being fed into the view.

This seems pretty fragile though. It will work only if (a) all further path args are always indeed valid arguments and (b) summary views can be displayed only as page views, accessed through a page path.

If summary views can be displayed on blocks or other non-page displays - can they? - we don't have a page path to work with. We'd need a way to parse the base path from the URL itself. Which is how I tried to do it first, but it felt messy.

Summary views can be displayed on blocks, but without a page view there's nowhere for them to go. Usually the way that works is that they then link to a page view using the link display feature (which is basically hidden if there's only one place for it to link to).

Which is to say...blocks aren't going to get ajax capabilities with summary views. Neither will anything else that doesn't have a URL path. So that's pretty much OK.

Applying hte patch in #19 actually broke AJAX use for tables, and didn't seem to make it work for summaries. I was testing with the built in 'glossary' view, which is probably the best example where AJAX with summaries would be useful.

Here's a reroll.

Changes since the last version:

* Added a call to scroll the window to the newly-loaded content
* Fixed up for multilingual support--needs to respect language path prefixes

Did some basic testing on the glossary view, appeared to be working. Could use some more testing.

Fix a couple of loose ends in previous patch.

I'm noticing a couple of issues.

* In the glossary view, non-alphanumeric characters are not correctly parsed and so fail to load.
* There's a flicker when the glossary view loads. I suspect there may be a double AJAX call, with one replacing the other.

Updated patch addressing the two issues I noted in #24.

The first was easy: use decodeURLComponent to decode the data passed as views arguments.

The second was trickier. When we have attachments, we get nested views. This means that by behaviours were attaching twice, once for each view being processed.

For summary views to work, we want to parent view's data. And we don't want to load into just the summary view output--we want the whole view to be replaced. If the summary view were to load into itself, we would lose the summary and get two node listings (the original one, plus the new one that loaded where the summary attachment used to be).

So the answer seems to be to skip processing for nested views. Here's the code I've added to do so:

       // Don't attach to nested views. Doing so would attach multiple behaviors
       // to a given element.
       .filter(function() {
         // If there is at least one parent with a view class, this view
         // is nested (e.g., an attachment). Bail.
         return !$(this).parents('.view').size();
       })

This takes care of the flickering, which was caused by double AJAX loading.

I haven't tested this in summary views that are *not* in attachments. TBD: what happens then, and what is the expected behaviour?

AJAX in summaries when not in attachments is questionable and for the moment I'm happy punting that question. I can easily envision use cases where you might want *both* and we don't currently have the capability of asking. Perhaps summary styles will need to specify specifically if they should support AJAX or not. That's ok for the future.

This patch checks out nicely with the glossary view and is in fact quite useful.