[NigelParticipant]

Ah ha, so its the unboundedmode that you believe is causing the issue? you could have just started with that. I’ll take a look at that.

The reason for using unboundmode is that I need the spreadsheet functionality. As per here:

http://www.jqwidgets.com/create-a-spreadsheet-with-jqxgrid/

I need spreadsheet mode, so I need filtering and sorting and editing all server side. I have integrated all of these examples, and they all work well independently.

As I said in my previous post. I apologies for the jsfiddle to give you information that you could use to help. Please can we forget the jsfiddle ever happened.

As I also said, on my server I do have, as per the edit example, a working updaterow callback and it works perfectly as per the video I posted, returning a “1” to indicate success and to trigger the commit() function. I may have mentioned, but I’ll mention it again. the updating works fine on my server if I edit any row that is not sorted. Exactly as per the example. The updaterow callback does not specify any of the paging or sort parameters that are added automatically in the other examples.

Pointing someone at the examples and documentation is fine as long as you give them a hint of what they need to look for. Or, if the documentation explained more about some of the settings, or possibly had a search function.

[NigelParticipant]

Then can you please help.

So should the update call return the data? This is not what the example/documentation does, and this does not work. When my grid returns an empty list the grid is indeed empty, no grid lines, no rows. That is also not happening here. I have gridlines, I have rows, I can navigate, the pager says I have data. It’s just blank, and sometimes some data is present in random rows.

In fact I cannot find an example that covers server side editing and sorting, so I’m just guessing that the integration of server side editing and server side sorting should work as the independent examples show.

I have shown you exactly what my server does including the returns it provides. I have attempted to provide a demonstrative example, but ok, it won’t work properly, sorry about that.

Please, stop telling me to go RTFM when I have obviously done this to get as far as I have and obviously missed the one bit of information or setting that I need. I have implemented and integrated the multiple examples which your examples do not cover, and they all work independently so I must have done that mostly right. When I integrate them all I am getting behaviour that I do not understand.

WHAT DO I NEED TO LOOK AT TO FIX THIS?
WHAT MISTAKE HAVE I MADE IN MY CODE?
WHAT IS MY SERVER DOING WRONG?

I would be happy if the update returned with success and then nothing else happened, like editing any other field in the table. There certainly isn’t another call to the server to resort the list, and that is fine. Lets say I don’t want that.

There isn’t another call to the server to resort the list on my working server, but the list reorders anyway.

The way I have implemented this, based on the combination of multiple examples works fine sorting, and fine when editing, and fine when I sort a list but edit a different field. Different behaviour occurs when I edit a field that is sorted, and I need to stop it, or make it work. I really don’t care which.

[NigelParticipant]

Ok, I can see you’re getting confused with my wanting to provide you all the information you will need, lets take another look.

My actual server is doing the sorting on my real page. I can’t point you at my real page as its behind a login. I have made a video to demonstrate my problem on my server

https://www.youtube.com/watch?v=meBdA1t1vxU

In Summary:

1. My server correctly edits things because I copied the example. The update call returns “1” as per the example.
2. My server correctly sorts things because I copied the example and integrated it. The sort call returns all the data as per the example.
3. My server correctly pages and filters because I copied the examples and integrated them. The sort/page and filter call returns all the data.

I can’t find an example that sorts and edits on the server in the PHP integration section.

I wanted to provide you with an example, and the JSfiddle exhibits the same behaviour. I understand that virtual mode means do stuff on the server and probably won’t work in JSfiddle without implementing the /echo stuff, but it exhibits the same behaviour. on my server, no second call is made to reorder the list, but it happens anyway.

[NigelParticipant]

Tried returning all the rows again. it doesn’t work.

[NigelParticipant]

Have you tried my example I have provided. It does not do this. It reorders the list. On my server it also reorders the list without a second server call to do the reordering. The examples involving editing show that the return is just a single ‘1’. Should I be returning all of the data, now sorted again after an update?

[NigelParticipant]

Hi Peter,

I am not missing this fact, and yes it should be. My server side sorting filtering and editing is working fine, *except* when I edit a sorted field. In my head one of two things should occur. Either:

1. I edit the field, press return, the update is sent to the server, success is returned, commit is called, and thats it (which I guess happens in every other field I would edit), in which case I could do a refresh of the list if I wanted to.
2. I edit the field, press return, the update is sent to the server, success is returned, commit is called, the commit function recognises that I edited the sort column and calls the server refresh for me to get a resorted list.

what seems to be happening is:

3. I edit the field, press return, the update is sent to the server, success is returned, commit is called, and my screen is replaced with a whole bunch of crazy. Several rows being blanked, and some rows are reordered to the point that using navigation starts jumping around. No second server call is made to resort, but the data is reordered in a VERY BROKEN manner.

Kind regards
Nigel

[NigelParticipant]

Thanks Nadezhda, perfect

[NigelParticipant]

Hi Peter,

I have server side filtering which worked well, but the issue is I don’t get the icon buttons to engage it. They worked for a while, then stopped, then came back briefly, and now have stopped working again.

I have since added the filter row and it is pretty cool. I think I’m going to leave that there.

Thanks.
Nigel

[NigelParticipant]

Oh, I have found that if I use this:

showfilterrow: true,

The row is visible and works fine, but the icon it adds to the header is not clickable or in any way reactive.

[NigelParticipant]

Hi Peter

This is my point. The number of actual data rows is variable. The data in the database can range from 0 to 100’s of rows per list. Why 1000? There isn’t an ‘all’ on the paginator so 1000 seemed like a good big number to show all the rows in nearly all use cases cases.

The same logic applies on an empty ‘new’ list with only a 10 rows/page setting. There are still a load of HMTL elements being created ‘just in case they may need to be used but actually never are’. It just seems that could be optimized out so performance can degrade based on the actual data shown to the user.

If local data needs to be added, the DOM could be updated with new elements at that point since the user would be expecting a slight delay.

Thanks for bearing with me
Kind regards
Nigel

[NigelParticipant]

Hi Peter,

Come on, I have played very nicely so far.

I’m trying to understand why a product (your product) I have paid a fair bit of money for is operating because it doesn’t make sense to me, and you are not being very helpful. This could be the language barrier and if so, I apologise, but I am asking for help understanding the process that goes on when the page size variable changes when the actual amount of data being displayed is not.

How about answering these questions:

1. Why are 17,640 extra HTML elements being created when they appear not to be needed?
2. If they are needed, what are they for?

Kind regards
Nigel

[NigelParticipant]

Hi Peter,

I do get your point, but what ‘additional’ HTML elements are created for rows that don’t exist and don’t need to be rendered to the user?

With a page size of 1000, the height is still only big enough to show the 14 rows that exist. If you are creating elements for the other 986 rows that do not exist, this is a problem.

I have counted the DIV elements:

autorowheight disabled, autoheight disabled, 20 rows per page 3,714 DIV elements
autorowheight disabled, autoheight disabled, 1000 rows per page 3,714 DIV elements

Interesting, and understandable.

autorowheight enabled, autoheight enabled, 20 rows per page 1,618 DIV elements
autorowheight enabled, autoheight enabled, 1000 rows per page 19,258 DIV elements

I’m trying to understand why this is the case. What are the other 17,640 elements for? They are in no way useful since they don’t provide any more information to the user. These 17,640 elements should be optimised out until they are needed.

Kind regards
Nigel

[NigelParticipant]

Hi Peter

It should be expected that the performance would stay the same with the same data. I do expect, and am happy with performance degrading when I add more elements. Let me bulletpoint, and then you can point out where my understanding is flawed.

1. page size = 20. 14 rows are returned. a certain number of elements are generated and formatted
2. page size = 1000. 14 rows are returned. The same certain number of elements are generated and formatted because the same 14 rows are returned.
3. Autorowhight – This is a formatting thing that makes words wrap in cells. This is a default behaviour for DIV elements so switching it on will take a bit of time calculating the display height of the outer box switching it off will add more rows into the view… both points leading onto point 4
4. autoheight:true will size the outer container to the number of rows. In my case 14 regardless of the pagesize option, but dependent on the height of each row as in point 3. I understand that if I have 1000 actual rows coming back, 1000 rows will be displayed. Therefore, based on your previous comment, I agree, if I have a fixed height that only shows 10 rows at a time, and you are using some form of ‘windowing’ optimization a lot less elements will be generated in the ‘window’ at any one time.

In summary, I have 14 rows coming back regardless of the chosen rows per page setting, so I don’t understand how it should be expected that when I have 14 rows coming back speed is ok, and then when I have 14 rows coming back speed is then unacceptably slow… its the same amount of data, with the exact same structure, and the exact same number of rows, in fact the exact same 14 rows, generating the same number of DIV elements in the DOM. The only thing changing is the grids ability to show more rows if they were to exist, since they don’t exist anywhere, not even in the database, it seems some optimisation should remove this overhead until such time as there are more rows coming back… back to me agreeing with you that 1000 rows of actual data would be unacceptably slow and I’m happy with that

I have managed to create working jsfiddles with my data to show my point.

http://jsfiddle.net/nigeljohnson73/cnsd2qnw/3/
Settings (right down the very bottom):

    autoheight: true,
    // height: 1000,
    autorowheight: true,

14 rows returned, 14 rows displayed, 20 rows per page – navigation slow, 1000 rows per page – navigation unusable

http://jsfiddle.net/nigeljohnson73/cnsd2qnw/4/
Settings (right down the very bottom):

    autoheight: false,
    height: 1000,
    autorowheight: true,

14 rows returned, 14 rows displayed, 20 rows per page – navigation ok, 1000 rows per page – navigation unusable

http://jsfiddle.net/nigeljohnson73/cnsd2qnw/5/
Settings (right down the very bottom):

    autoheight: false,
    height: 1000,
    autorowheight: false,

14 rows returned, 14 rows displayed, 20 rows per page – navigation good, 1000 rows per page – navigation good

kind regards
Nigel

[NigelParticipant]

Oops, sorry for sharing my key.

These are indeed the culprit

autoheight : true,
autorowheight : true,

They both seem to negatively impact performance, which surprised me for autorowheight.

That is interesting though, there are only 14 rows of data coming back, regardless of what the page size is set to. That seems like an optimisation issue? If I actually had 1000 rows of data coming back I could probably see how things may slow down initially, and then potentially working out which cell to move to next unless this was worked out prior to navigation.

I have disabled both options for now, hopefully something optimisely will come along

Thanks.

[NigelParticipant]

As you can see from my code the ‘cellselect’ returns immediately without doing anything. The example also doesn’t do keyboard navigation within cells, and doesn’t have 1000 as a page size option. If this were a “my code” issue then the behaviour would be the same regardless of which paging size since the same 14 rows are returned whether I chose 20/page or 1000/page. The only difference is the operational code that seems to do something more on the same data when I chose more per page – even when there is no more actual data. I have tried switching of the filtering and sorting, unbound mode and caching… all having the same issue.

That said, I have seen the cell navigation example, and spreadsheet like integration and it is one of the reasons we chose to purchase a commercial license (8B7FE2CB-0572-4A4C-88F5-49D6694293BF – assigned to my boss).

Is there anything else I can look at to try and work out where the slowness is coming from.

[Author]

Posts