At this time, there is not a method for declaratively adding a ‘Select All’ option in the picklist for Visible Rows.

I see your point. You want to generally limit the Visible Rows for fast page loads, but, in the context of Mass Updates, you want to able to show everything. 

You might want to post this as an Idea and we will see if this gets picked up for some future release!

Lastly, an ugly way to force all the records to show within the context of needing away to mass update items: you could go into the model’s Advanced settings and change the Max # of Records to blank. This will force all of the records to load. Then, if you change the Table’s visible rows settings to All, you can make mass updates for all the records. Clunky, I know.

-Josh

I have this exact same need. In lieu of it being delivered declaratively in Skuid, maybe a little code might help. We could set the model’s max records to blank, set the table to return 10 rows (hence it should run pretty fast), then add an inline Javascript function. That script would use JQuery to add an extra entry of 500 into the “Select x accounts per page” (if it’s an account model) on the table. The user can select that and then do mass updates on 500 rows at a time. You’d need to train users so that they only select that many rows for this purpose, but it seems like it could work. 

I haven’t written that script yet, but I did a pseudo test in the browser by using the Chrome console to add the 500 entry into the table select. The mass update worked fine, so I’m encouraged.

Ok.  Here is a counterproposal. 
If your primary interest is speed - it makes sense to keep max records small and stay within the current pagination structures. 
But if you have a secondary interest in mass editability for data clean up - you are going to have to give up on spead of load time.   These two use cases might not make sense combined on one page.  Cloning a page is so trivial that it would see easy to set up a second page where the visible rows was set to 100 or show all.   This page could be linked from the first page. 

An aside Glenn;  There is  a problem with your proposal:  The max records property controls what gets loaded from the database,  while the tabel property merely arranges the pagination of all that data.  So if you have 10,000 records and set it up as you describe, the page will load all 10,000 before displaying.  (If it displays at all…)

But having said all that,  it would be elegant if there was a way of overriding both the max rows property and the visible rows picklist on the table so the user could ask to see everything…  We could call it the “table explosion button”

I think we can and should do this.  Since we’re just talking about client side here, performance isn’t as much of an issue.  (Although it could take a while for certain browsers to render 1000s of rows.)  Glenn, If you want to use an unsupported method for changing the page size, you just need a reference to the skuid list object.  Once you have that, you can do this…

list.currentPageSize = 500; list.render(); 

I hope to have a more formal, documented API method for changing the page size of a list in a future release.

Thanks Rob and Ben. Some great ideas there. Rob: we also had that idea of a separate page for mass updates. (Its code name at PractiFI is the BFT, standing for Big and Table, and you get to choose your own F-word.) We’ll probably do it, fill it full of fields and filters, and set the maximum rows high as you say. But we might also take on Ben’s idea in our existing pages

Is the max record number before or after the filters? For instance, I need to show all records for this month. Or show all that are not checked reconcile. So I have my object filters set up to display correctly and limit the results. But I have my max record set to blank so I don’t miss any. . . We don’t have years of data yet, so right now it is working. The filters will always keep the displayed rows manageable. But will I overload the system prior to it hitting the filters at some point with this system? Is there a best practice? Thanks for the help!

The Max Number property affects all queries on the model.  
- When you load a page - that’s how many records will be retrieved.  
- When you execute a filter or a server side search - you are actually running another query to the server - hence the Max Number affects how many you get back.  
- When you hit “load more”  you get another incriment of records in the size specified by your Max Number. 

The only exception to this rule is client side search,  which filters only on the records currently in memory.

And yes - eventually your queries will have problems as you get more information in your system. 

I have 3 more clarifying questions. Thanks for your patience. I think it is a needed education for me though to understand how I may hurt my project in the future. 1. If my filter is set to Always On, is that what drives what is pulled/retrieved the first time the page loads. I.E. Let’s say I have 1 million records. I have a filter that is set to “always on” that would limit the total records to 500. Does that first retrieval pull 1 million records in or does it look at the filter which is always on and then pull in the 500 records according to the filter? 2. Same use case we have 1 million records but the User Profile only has security access to 100 of the 1 million records. Does the model pull in 1 million or does it pull in 100 according to the users security model? I know it will only show them the 100 based on security but do we risk breaking the page if the number is set too high. 3. We are using the Calendar to create a master calendar where the view is controlled by Salesforce sharing rules (i.e. What geographic area they are assigned to). I do want to show all calendar events (or at least those in the recent past and into the future). Is there a point when I risk breaking the calendar page if I have too many records. Is there best practices for these use cases. Thanks for your help, I am trying to future proof my nuild to elimiate surprises.

These are all good questions. 

Answer to 1 and 2 is that the full Million records will never be retrieved.  The Always On condition will dictate the original query,  and Record Level security will dictate rows returned by that original query.  In both cases you will start with the much narrower number (and the specific number of rows will be determined by your Max Records property for the model) 

Answer to 3 is Maybe.  There will be a point where you can’t really read all your calendar events because there are too many of them stacked on top of each other.  I don’t think we have precise guidelines for when that will occur,  but I suspect you’ll know it when you see it. 

There really are not specific best practices here because each skuid page is something of a special case.   The general best practice is to only provide users with the data they need to immediately interact with so that loading times are reasonable.  Let them load more or search for more in order to get full data sets. 

Can we also change the text on any list page (in table) like campaign per page , so here i want to change the campaign …is it possible?

Sorry Rimali,  you can not change the text that shows below the table in the pagination section.  You can change what shows in the search box, but not in the pagination section.