I’m struggling to understand the default paging behavior of tableviews in webclient. Specifically how does one programmatically set (or reset) which page is being viewed? Is there a way?
What I am running into now is that the current-selected page persists across show events/page reloads. Meaning that if I am looking at a tableview of 1000 records and ea. page is show 100 records, and I choose (manually by clicking) page 2, I will then be looking at a table-view with a list of records starting at record #101 etc. If I then leave the tableview, then come back, the page number is still set to 2. It should reset to 1 in my opinion as this is default behavior on the web/for web applications (unless you were saving your page somehow or passing it in the url as a get param). Typically a selected page does not persist across page reloads, but it does here.
How can I fix this? I have tried to set the selected index to 1 on the table-view’s foundset, which I was hoping might also force the paginator to go to page one, but of course it just sets the selected index to the first record on the current page.
Update to this: I just realized that controller.setSelectedIndex(1) will force the pager back to page 1. foundset.setSelectedIndex(1) of course will not.
Actually it can be quite handy that the page state is persisted, and if you prefer to simulate a stateless web page as you said using controller.setSelectedIndex(1) it works too.
The fact that the page state is persisted is a feature: What if the user is browsing 150 records in pages of 10 and hey’s at 130. He sees an interesting record, clicks it to go to the details and then goes back: would be very annoying if he’d be on record one again.
Both foundset.setSelectedIndex() and controller.setSelectedIndex() should work exactly the same. If it doesn’t please report this as a case.
pbakker:
The fact that the page state is persisted is a feature: What if the user is browsing 150 records in pages of 10 and hey’s at 130. He sees an interesting record, clicks it to go to the details and then goes back: would be very annoying if he’d be on record one again.
Both foundset.setSelectedIndex() and controller.setSelectedIndex() should work exactly the same. If it doesn’t please report this as a case.
Paul
Hi,
I was surprised to read that foundset.setSelectedIndex() and controller.setSelectedIndex() have a different effect (in Webclient ?).
In more than one topic I heard from Johan that controller or foundset should not make a difference…
But… I do see a difference in behaviour between Smartclient and Webclient with regards to setSelectedIndex and returning the selected record/index in UI view when having multiple pages in tableview !
Smartclient ok, webclient not ok.
The fact that the page state is persisted is a feature: What if the user is browsing 150 records in pages of 10 and hey’s at 130. He sees an interesting record, clicks it to go to the details and then goes back: would be very annoying if he’d be on record one again.
Both foundset.setSelectedIndex() and controller.setSelectedIndex() should work exactly the same. If it doesn’t please report this as a case.
Paul
Well it may be a feature, but it is very un web like, and we need a way to reset a list of records to page one. Typically in web applications/web programming only information that is specifically and explicitly persisted is available beyond the request and response cycle. This feature is very implicit. If it is desired to have the selected page number persist then we need a way to un-persist it. Right now, I have found that controller.setSelectedIndex(1) does this. Whether or not it should I don’t know, but it does.
There is a problem with this feature however…
Consider lazy loading…what if your fs has greater than 200 records, and you are looking at 100 at a time (100/page). Originally your pager only shows two pages, then when you click on page two you see more pages. Let’s say you then click on page 4 (you are now viewing records beginning at 401). If you leave that page , then come back, and if when you come back you reload the fs, webclient will place you on page two (b/c it is trying to persist/remember the page number), not on page four, bc there is no page four yet. This is very awkard when it happens.
I’m not really following exactly what you’re saying, but fact of the matter is that with Servoy you create applications, that happen to run in the browser. It’s not a stateless webpage.
The paging will remain the same if you hide and reshow the form, unless you take control into your own hand, using .setSelectedIndex(). If you use that, Servoy makes sure that the page containing the index that you selected is shown.
You scenario that you’re on index 401, hide the form and come back and all of a sudden you’re on 200 doesn’t make sense: you should still be on 400, unless you took control into your own hands and reloaded the foundset or selected another index.
but fact of the matter is that with Servoy you create applications, that happen to run in the browser. It’s not a stateless webpage.
That’s fine, but an application that runs in a browser needs to behave like a web application. I can’t exactly tell users that their web application isn’t really a web appliation, instead its an appliation that just happens to be running in a web browser.
But that’s fine, I follow you.
The paging will remain the same if you hide and reshow the form, unless you take control into your own hand, using .setSelectedIndex(). If you use that, Servoy makes sure that the page containing the index that you selected is shown.
foundset.setSelectedIndex() does not work for this. controller.setSelectedIndex() does (I have no idea why)
You scenario that you’re on index 401, hide the form and come back and all of a sudden you’re on 200 doesn’t make sense: you should still be on 400, unless you took control into your own hands and reloaded the foundset or selected another index.
Correct, and that is actually what I said in the post…“if you reload the foundset.” And there is a disconnect here, b/c in my mind if you reload the FS your page shouldn’t be persisted. That page may no longer exist. This is actually what tripped me up originally. B/c I reloaded my FS and expected to be back on page 1, but was not.
Did you do a search? or did you just load a different foundset in through the controller? (if the latter then the selected index of that foundset is used)
About Web applications, they are meant to really make an application in the web, websites are different, web applications should try to be as close to a native web app as possible. Thats the whole point of a web application
I reload the foundset by issuing a foundset.clear() and then by using foundset.loadRecords(myRelationName).
I actually have another issue with paging in addition to this…
When I have the same table-view form place on a tabpanel with different relationships, and if the tabpanel component is anchored bottom (grows vertically), the pager will only redraw to take the full screen height (increase the row count) for the first tab, the first time it is loaded. As I click from tab to tab, which is loading a new foundset into the placed form, the row count doesn’t refresh to take up the vertical space, it stays locked at the specified height of the tabpanel component itself. And since I have no way to programmatically re-page/refresh the pager the only thing I can do to make the pager grow the row count is to grab the drag handle of the window and resize.
then the foundset doesn’t have to be on page 1, because if you copy 1 foundset into another like that we also copy the selection.
So the selection you get is from the related foundset.
after you set reload the foundset
also set the foundset index to 1 with the call setSelectedIndex that should work fine
If not make a case and with a sample solution so that we can look
If I setSelectedIndex(1) on the FS and then I call getSelctedIndex() I will get 1, however if I am not on page one when I call setSelectedIndex, the pager does not go to page 1.
foundset.setSelectedIndex does NOT repage/initialize the pager to page 1
controller.setSelectedIndex DOES repage/initialize the pager to page 1
jbader:
When I have the same table-view form place on a tabpanel with different relationships, and if the tabpanel component is anchored bottom (grows vertically), the pager will only redraw to take the full screen height (increase the row count) for the first tab, the first time it is loaded. As I click from tab to tab, which is loading a new foundset into the placed form, the row count doesn’t refresh to take up the vertical space, it stays locked at the specified height of the tabpanel component itself. And since I have no way to programmatically re-page/refresh the pager the only thing I can do to make the pager grow the row count is to grab the drag handle of the window and resize.