Hi, I’m currently evaluating the itmill toolkit for use in a larger web application. We’ll be generating forms with several hundreds components and I was wondering how well the toolkit will be able to cope.
Is there any recommendations on how to layout components in order to achieve good performance?
Is there any plans to support paging in the Table component (i.e. multiple pages with next/previous buttons)?
You have at least two options to implement this immediately:
if the reason you want paging is that it should not load everything into memory at once, then you have that already. When you open a page with a big table it will just load a subset of the data range. It will start fetching more items when you start scrolling - thus loading only what you need and minimizing the traffic.
If you want the paging for a visual reason, then you can just follow Mr. Anonymous instructions.
First, are you talking of server side performance (application server cluster) or client side performance (web browser)?
Client side performance is easier to test, just run your application with single browser and if speed is not enough, inspect further. Scalability is typically not an issue here as we can say that this does not depend on how many users use your system concurrently.
Server side performance is another case, it directly depends on how many concurrent users you have using your system. Based on my experience it has little to do with Toolkit stuff as it is lightweight, all performance challenges have existed on business logic or database side which has nothing to do with Toolkit. Therefore, open up your JProfiler and profile your data layer 
For server side throughput you can consider shared static Toolkit data components (IndexedContainer, HierarchicalContainer…) which are forced to read-only state. These containers may contain data that is costly to initialize per every user / session, therefore we initialize a cache to all our UI servers. From the cache every user may instantly access Toolkit containers.
If you want to hear more, just ask.
Thanks for the quick replies!
Actually, the reason I want paged tables is that the scrolled table caches rows before and after the visible page (two pages before and after I think).
Now this is usually what I want, but in one table I have a lot of embedded components (checkboxes, comboboxes, datepickers, etc.) and can actually see the individual rows being rendered. So I thought if I had a paged table then only the rows visible in the current page would be rendered and it would be a lot quicker.
I also suggest that you create a test that adds several hundreds of Toolkit components in your views and see how browser can handle your UI in the client side. This will give the best answer for your specific use case.
We’ve run these kind of robustness / load tests using our Testing Tools, using deterministic random behavior in which random layouts with random components are pushed to the client side and then tested how client’s browser can cope them.
Yes, I was talking about client side performance, or more accurately IE performance
I have done some initial testing just to get an idea of the rendering performance. As I mentioned in my first post, we need to dynamically generate forms with several hundred components and, unfortunately, we have to support IE.
Thanks!
Yes, table do cache some extra rows beyond visible area in order to make scrolling more smoother - if you’ll scroll row by row, there will no immediate fetch request and therefore delay. You may adjust this by setting a custom page size for the table component, so it will prefetch less or more records in advance.
Regarding paginated table - do not forget to properly implement your server side data container, so it will also fetch data from the database (whatever else) by request and not put entire dataset into the memory (see hibernate container for example), or you may run into memory problems at the server side.