Using Tables with the TablePaginator and Maintaining State

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Using Tables with the TablePaginator and Maintaining State

Scott Gurney

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]

 

Reply | Threaded
Open this post in threaded view
|

Re: Using Tables with the TablePaginator and Maintaining State

gilbertoca


2013/11/19 Scott Gurney <[hidden email]>

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]

 


Reply | Threaded
Open this post in threaded view
|

Re: Using Tables with the TablePaginator and Maintaining State

Scott Gurney
Thanks, Gilberto. I should have been clearer and maybe in my ignorance I am missing something quite simple. You see, I am having issue with the state of the page. Not the state of the table.  The request parameter is bound to a page public variable.  If I save the state of the table it does not save the request parameter. Does that make sense?

On Nov 19, 2013, at 3:31 PM, Gilberto <[hidden email]> wrote:



2013/11/19 Scott Gurney <[hidden email]>

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]

 


Reply | Threaded
Open this post in threaded view
|

Re: Using Tables with the TablePaginator and Maintaining State

Sven Pfeiffer-2
Hi Scott, 

you can add parameters to the tables pagination- and sort-links using the tables controlLink property.



Regards
SVen


On 19 Nov 2013, at 22:14, Scott Gurney <[hidden email]> wrote:

Thanks, Gilberto. I should have been clearer and maybe in my ignorance I am missing something quite simple. You see, I am having issue with the state of the page. Not the state of the table.  The request parameter is bound to a page public variable.  If I save the state of the table it does not save the request parameter. Does that make sense?

On Nov 19, 2013, at 3:31 PM, Gilberto <[hidden email]> wrote:



2013/11/19 Scott Gurney <[hidden email]>

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]

 



Reply | Threaded
Open this post in threaded view
|

Re: Using Tables with the TablePaginator and Maintaining State

Bob Schellink
Administrator
In reply to this post by Scott Gurney
Hi Scott,

What Sven mentioned could help.

If it is a Page variable you need to persist, you could also put it in the HttpSession:

getContext().setSessionAttribute("variable", 123);

regards

Bob


On Tue, Nov 19, 2013 at 11:14 PM, Scott Gurney <[hidden email]> wrote:
Thanks, Gilberto. I should have been clearer and maybe in my ignorance I am missing something quite simple. You see, I am having issue with the state of the page. Not the state of the table.  The request parameter is bound to a page public variable.  If I save the state of the table it does not save the request parameter. Does that make sense?

On Nov 19, 2013, at 3:31 PM, Gilberto <[hidden email]> wrote:



2013/11/19 Scott Gurney <[hidden email]>

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]

 



Reply | Threaded
Open this post in threaded view
|

Re: Using Tables with the TablePaginator and Maintaining State

Scott Gurney
Thank you Gilberto, SVen, and Bob!  I'm going to play around with this and see what I like best.  I'm also considering changing the flow of the app somewhat by adding a Select control right on the same page and having the user choose the data to display. That way I can use the very handy saveState() for the control. 
 

On Nov 20, 2013, at 12:09 AM, Bob Schellink <[hidden email]> wrote:

Hi Scott,

What Sven mentioned could help.

If it is a Page variable you need to persist, you could also put it in the HttpSession:

getContext().setSessionAttribute("variable", 123);

regards

Bob


On Tue, Nov 19, 2013 at 11:14 PM, Scott Gurney <[hidden email]> wrote:
Thanks, Gilberto. I should have been clearer and maybe in my ignorance I am missing something quite simple. You see, I am having issue with the state of the page. Not the state of the table.  The request parameter is bound to a page public variable.  If I save the state of the table it does not save the request parameter. Does that make sense?

On Nov 19, 2013, at 3:31 PM, Gilberto <[hidden email]> wrote:



2013/11/19 Scott Gurney <[hidden email]>

I'm looking for some guidance from any Click users who have used Click Tables in their work.  In particular, I'd like to know any "rules of thumb" for designing pages (or sequences of pages in a workflow) so that table pagination works consistently.

 

You see, I have a first version of a relatively simple application built using Click.  In one sequence of pages in a workflow, I'm using a request parameter from the query string to dynamically choose the data to display in a table of results.  The obvious problem with this approach is table pagination doesn't function properly because the original query string is not maintained between requests. So page 1 of the table works but none of the other pages in the table do.

 

Anyone else run into this, choose to continue using request parameters, and find an elegant way of saving state?  I'm second-guessing altogether my approach of using a request parameter for this purpose. 

 

Any thoughts are appreciated.

 

Scott

[hidden email]