CreativebyteHello tony,
I read your previous post again and you fell for the same mistake that was the basis for this bug report: You did a simple exted and not a deep copy! It seems that the second level of the options array (in your case the rowList) is not copied but linked, which causes the overwrite. So, if you do a deep copy like I suggested
$.extend(true,$.jgrid.defaults,{rowList:[10,20,30]});
you won't have any problems 🙂
On the other side, I use a different approach. I don't want to mess with the defaults since you never know if you won't get a new module in the app where you need to change it all back. Most of my grids (90%) use a lot of common options and they only differ in minor things (like postData and stuff).
My solution was quite simple. I have a default array per “grid group” where I store all common options and a specific options array for each grid in that group to set the specific options or even override the ones in my default array.
Having this, I run the extend function (deep copy!) on both arrays and get a combination of both in return. After doing this, I pass this array on to jqGrid. By doing this, the jqgrid default array remains untouched but I can define my own defautl array per group. maybe, this could be an enhancement for the library?
My idea would be: let the developer define multiple default arrays (named) when setting up the library.THis default woudl sit on top of the standard default array.
On each grid, he can choose whether to use the standard default array or one of the ones he specified before. Afterwards, he could overwrite those values as well as he can do now with the standard default array.
So, all I want to say is: why not bring an additional layer in between the standard default array and the grid specific options? In my code this would be really helpful (that's why I do this already but outside the library).
CreativebyteHi tony,
I got no problem since I don't overwrite the default array. All I do is to store all my jqgrid options for all grids I use in my app in a big array-structure and since you do a deep copy now everything works fine for me.
CreativebyteSorry, I still don't get it. The only thing that jqgrid knows about the pager is just the jquery selector from the options array. By using this, you do everything, starting from showing the whole thing to adding buttons and navigation images to it. So, Why does it matter where the pager is?
Anyway: if you don't want to set the scroll class automatically it's ok.
CreativebyteHi tony,
I don't get this reason. Of course I can put the pager html element where I want. But since you have the jQuery selector of the pager, this doesn't matter, does it?
So, in my opinion it's like this: when a pager selector is given you set the class scroll automatically. You could even bind this on viewrecords:true if you like.
BR,
Creativebyte
CreativebyteNotice:
For adding my feature (if you understood the existing one it in another way) it is quite easy: If pginput is false, simply don't include the sp_1 and selbox items to the html code. By doing this, you can remove the if in line 651 in the base js, since the filling can be done in any case (if the items are not present, no filling is done by jquery).
Maybe this helps implementing this feature or changing the existing implemtation so that it sticks to the docs text.
BR,
Creativebyte
CreativebyteAdditonal notice:
Why do I need to give the pager the class “scroll” anyway? Can't you do it while setting up the pager? Would save a few bits and would help gettign around this check completely…
For solving bug1 I already did it in my code. Just exchange your if() with:
if( $(ts.p.pager).attr(“class”).search(/scroll/) != -1)
and it works. But for rewriting the hiddengrid method: I have no idea how to do it quickly and I am prettyl ucky that I need the pager there…
CreativebyteHi Tony,
Good to know, thanks. But if you could provide a one-shot function like lockRow() (maybe with an additional callback function when clicked (fpr displaying custom error messages) and a varaible for color) or something it would be great!
BR,
Creativebyte
CreativebyteThanks a lot!
CreativebyteHello Tony, Brad,
I would like to support this feature request but in a different matter. I use jqGrid on an administrative website that allows the administrator to change certain list values, add new ones, etc etc.
As you may know, changing settigns that are in use or even deleting them would cause a lot of problems, the smallest one that it is messing with the data that the user has entered.
So, I would like to have a possibility to lock certain rows (best of the best would be to do this based on a cell value, e.g. if the row “in use” has an “x” value) so that those can't be selected and maybe even colored in a different way.
At the moment I do this myself in the loadComplete function, but to have this as a standard feature would be great.
Thanks,
Creativebyte
CreativebyteHi Tony,
I found it out myself yesterday but as I said: I think that the default setting is not good. Why do I need to change a value that – I think – nobody can use unmodified? The best solution would be the use a default value that suits the needs of most users and I think thats 100% and not 150 pixels.
Can you do a survey on this forum? Would be interesting to know. From my perspective, I see no use in a fixed pixel value at all…
Br,
Creativebyte
CreativebyteHi Tony,
Neither did I, it took me a couple of days a going through raw jquery source code to know what's happening. As I said: I did the modification and it's working perfectly for me. The only difference in the extend behaviour is, that the complete object is really copied and not only the first level (“lower” levels are passed on by reference). jQuery sourcecode on this function is quite easy to read, if you do you will notice there is nothing to fear about.
I also did a quick snippet werwe you can see the effect:
Copyright 2014 TriRand LtdAll Rights ReservedRSS
Back to Top