As usual ... Thanks Fixed.

Tony

Great that github is working for you again!

I noticed one odd change: 5a4510e47e65d21a0681a20d72111753c2ae8459

Thank you for this post.

Let me discuss a little bit.

1. The article that you post say that JSON is secure and eval is not safe.

It is not really true. I think that there is not complete secured thing. This is true for JSON too. I recommend you to read this http://directwebremoting.org/b.....it_is.html

in order to understand what is happen. Another good link is here

http://solutoire.com/2007/03/1.....your-json/

2. Appling JSON parse direct to jqGrid will cause the most user not use jqGrid. The reason is how the user configure your response from the server. Let make a example:

I think you see the difference. When we use standart json encoder like in PHP json_encode and (there is such one in ASP) all is ok, but in case that this is not possible the most developers write thier response like in variable b. If you read the most messages in this forum connected to json response, you will see that about 50% of the responses that users post here is like the variable b.

But when goes to speed improvements I'm open and redy to apply them if they will not brake the existing code.

For my pleasure I have made some tests only in FireFox 3.5 comparing the times of parsing and I'm surprised how JSON.parse if fast.

The tests vary, but parsing 4 columns with 300 records - take 1ms with JSON.parse and 10ms with eval - wow 10 time faster.

In order that all will be happy I introduce another option in $.jgrid object called useJSON (default false) and have made the needed changes to the parse function (also published in the GitHub)

3. About the second I think this is great and as you can see it is already in the code.

Best Regards

Tony

Now all is OK with the Git (moving the repo to Ubuntu).

Have merge the your last commit.

Regards

Tony

I have a chance to push only once and nothing more. My saga with the Git continue. I can not push anymore.

I have do a lot of other fixes, but...

Tony

Not a critical bug, but I noticed your last git update didnt include my commit: d8effc6f310560ddd1d5ba4cbf73f5b9b00a774a

It probably wont affect anyone but me, and I have the fix :-), but just FYI

Mark

jhsu said:

As for the retrieving data part, the behaviour of hitting the server several times before the mouse is released from the scroll bar seems to be consistent across all the browsers I tested, IE6, IE7, firefox, Safari and Chrome.

So the problem here is that you dont know when the user releases the mouse (or at least, I dont - perhaps there's a way!).

What happens, is that you get a series of "grid scrolled" events. To try to prevent hitting the server too many times, Ive set it up so that when a grid scrolled event occurs it kicks off a timer. If no new scroll event occurs within the next 200ms, it fetches the data, if a new one does occur, it resets the timer.

Perhaps 200ms is too short - but much longer than that and it will seem unresponsive.

Mark

1. Some of the newer browsers now have a native JSON object which allows for improved performance in JSON parsing over using “eval” (see: http://encosia.com/2009/07/07/.....security/).
2. Because of a workaround for an XSS vulnerability, ASP.NET 3.5 started wrapping return values of WebServices into a “d” object ( see: http://encosia.com/2009/06/29/.....s-d-again/ ).

In grid.base.js, replacing the following line ( should be around line 56 in the file ) in the "parse" method

with

would address both native JSON parsing and the new “d” wrapper object in ASP.NET 3.5.

For the second issue with page scrolling, the display problem seems to occur in IE6 and IE7 only, especially when the grid gets reloaded by the following code:

However, i find that the page scrolling features from the v3.6 demo works great on IE6 and IE7.

As for the retrieving data part, the behaviour of hitting the server several times before the mouse is released from the scroll bar seems to be consistent across all the browsers I tested, IE6, IE7, firefox, Safari and Chrome.

Thanks again for being so quick with your reply.

Thanks.

About the first issue - just now I have do the fix. It will be available in the final 3.6 Release.

About the second I have only once such situation, but currently I can not reproduce it again. Will continue to investigate the problem

Regards

Tony

First of all, I'd like to say jqGrid is a fantastic plugin. The best I've seen so far for web apps with the feature set and performance offered. Thank you so much!

Now with the issues I've experienced with the latest v3.6 version (as of Nov 3) I played with:

1. CSS display issues with the paging bar at the bottom of the grid: On IE6 and IE7, the total pages indicator seems to be wrapped and pushed off to the next line when the number has more than 3 digits. On firefox, safari and chrome, the row number select list is cropped slightly to the right. see [Image Can Not Be Found] ()

2. Paging with scrolling feature: sometimes, the content of the grid does not display after scrolling, even though the data comes through from the server. Also, the scrolling feature tends to retrieve the data several times while the user's mouse is still in scrolling. I think it'd be better if it could be made to retrieve data once after the mouse button is released from the scroll bar.

Thank you again with your amazing work on jqGrid.

The today release for the 3.6 version of jqGrid is changed for November 8, 2009.

The reasons are mostley connected with some problems in GitHub. I hope that they will be corrected to this date.

I have published a 3.6 RC which can be downloaded from the same place of the original blog post for 3.6 beta again with the demo files. Also the zip contain Changes.txt file with all fixes, news and changes.

The documentation in the wiki is updated to this release.

I think that this is very impresive – the docs are redy before the release

Best Regards

Tony

The ie6 scrolling problem and various other scroll issues are fixed in the latest github. I think my latest fix (for MarkC) isnt there yet because tony is having problems with github 🙁

The bgiframe issue: all the other dialogs use jqModal, and I think it has a bgiframe equivalent built in. The column chooser is actually very customizable - you can use essentially any "unobtrusive" mutiselect plugin, and any "dialog" - its just setup by default to use ui.dialog and ui.multiselect.

The reason is that I initially implemented it outside of jqgrid for my own project (which already uses multiselect and dialog) - and then realized it would make a nice general purpose addition to jqGrid. If I get time, I'll figure out how to set it up to use jqModal instead of ui.dialog, and post an example.

Mark

markw65 said:

The bgiframe trouble can easily be solved: turn on bgiframe! (include bgiframe in your header, and then set $.ui.dialog.defaults.bgiframe = true)

I'll try to take a look at the loading while scrolling problem tonight…

Mark

Hi Mark,

I agree this will probably solve the issue, but have a look at all others dialogs of jqgrid (in the demo), they don't need it.

Ex in "NEW API" from 3.6 demo, open the "search" modal dialog, you'll see the paging combo will disappear, without us having to include anything ? Why applying a fix only for the new column chooser (BTW really nice job on it).

I also saw your scrolling problem reply, and hope you'll find a way to fix it, IE 6 is a real mess to deal with 🙁

Aurelien

Yes. The footer shold have the consistency of the header.

Fixed.

Also I wait for the support response from GitHub

Tony

One more small bugfix. remapColumns didnt update the footer when updateCells was false. This is wrong, because even if you rewrite the footer, it doesnt regenerate the td's, it just sets their contents.

Mark

Liam said:

Hey guys, I was wondering if I will be able to use the column reorder functionality to return the new position of a column, or some other way to access the order of all of the columns.

After column reordering, colModel is updated with the new order.

You can use $("mygrid").jqGrid("getGridParam", "colModel") to get the array. Also, by default, the current permutation is recorded in the "remapColumns" array.

Mark

}

tony said:

I have merged the changes, but today I again have no luck with GitHub, so You can't see them.

Might be worth posting about this on the github support site... I was having similar problems (push would fail intermittently, and clone failed 100%) a couple of weeks ago, and they found some inconsistencies in the database, which they were able to fix by running git gc at their end. My problems went away...

Mark

Liam

I have merged the changes, but today I again have no luck with GitHub, so You can't see them.

My first test are OK with these changes.

I will hold down 3.6 release for some other days, untill I'm sure that all work OK.

Tony