afterAjaxUpdate property in CGridView

I have a grid in the view, then I try to generate some chart from the grid. When the pagination and sorting links are clicked, the grid will change value, I am trying to update the chart correspondingly

However when I use afterAjaxUpdate property in CGridView, I found out that the data returned is the whole page instead of just the grid part.

Anybody has the same experience?

Thanks

Sorry, for late reply!

Yes, I have exactly the same problem. And was just about to write to ask about it.

I just wanted to display myself an AJAX passed to CGridView in update request, so I used:


<?php

    	$this->widget('zii.widgets.grid.CGridView', array

    	(

            	'afterAjaxUpdate'=>'function(id, data){alert(data)}',

            	...

    	));

?>

But even if the documentation says that:

the result of above mentioned function is whole page source displayed in alert, not just the AJAX request.

Has anyone got any idea, what is wrong?

Nothing is wrong… as it says "data" is the received ajax response… and by default all the page is returned… as render() is used

If you need only the gridview… than you should create a view file only for CGridView and return a renderPartial() of that view

Aaargh! :expressionless: Definitely need more coffee! :expressionless: I misspelled response with request. I was reading response and thinking request. Of course, everything is OK, if reading response and understanding this as response! Damn! :expressionless:

No, a don’t want to get just the CGridView. I’m seeking (just as I wrote) for an solution, where I can display myself an AJAX request (that is request, not response! :]) that was passed to CGridView and that caused it to refresh. Just purely for testing purpose, to see if my search form is passing what it is suppose to pass.

Just to clear things a bit… so that we know we are talking about the same thing :)

An ajax request is not sent to CGridView… it is sent to an action in the controller that in turn renders a view where CGridView is used and that in turn calls $model->search() to filter the data…

If you want to see the URL that is called to obtain the filtered CGridView you can use beforeAjaxValidation like:


'beforeAjaxUpdate'=>'function(id,options){alert(unescape(options.url)) }',

I just noticed that in the docs the second "options" parameter is not documented…

Edit: documentation fixed in trunk

I really, really, really need a coffee! :]

What you just wrote is an professional, clean way of achieving this. I found a dirty way of doing the same. My method consists of changing $(’#search-form form’).submit) in view rendering CGridView into something not correct (for example $(’#search-form form’).click). This makes submit to work in non-AJAX mode, with page reload and then you can see URL in browser’s address bar.

But I was afraid to post it here (as someone could vote me down for it! :]) as I know this is a very bad practise and that is why I asked for a better way to do it! :]

All solutions are good if they work and if they help to make better code :)

Anyway with firebug you don’t need all this… there you can see the parameters passed, the request/response headers, the plain response and HTML response

I’m using it constantly…

Yes, it is very powerful! Unfortunately, I’m using it only like for about a few days (just discovered it) and for example, have no idea how to configure it (or CWebLogRoute) to see SQLs! :] Sounds familiar? :]

A small Firebug 101…

First of all right click on the firebug icon and select "enable all panels"…

if you just enable firebug… you need to refresh the webpage so it reloads with firebug enabled… after that every sorting or filtering in gridview will log in the firebug console a GET request with a complete URL and a small + in front…

just click on that + and you can choose to display Params - Headers - Response - HTML

Thanks for a short Q&A, but all of what you wrote was already known to me! :] I’m trying to figure out, why I can’t see SQLs from my application, neither in Firebug, nor on a page. But this is covered in a different thread, therefore, there is no need to repeat this here.