Cloned from launchpad blueprint https://blueprints.launchpad.net/horizon/+spec/filtered-client-side-table.

Description:

Summary
=======
Provide standard table behavior for the Admin Instances table (total count, filter, sort, page) in a way that can support other tables in the future. Separate the filter from the table, so that the table can process a client-side dataset of limited size.

Motivation
========
Current table UX is prohibitive for >20 items. This BP:
- Adds "Previous" button, paging backward through client-side data.
- Sorts all items (not just current page) with all columns, using client-side data.
- Shows current position in entire dataset  by getting total count from API.
- Filters multiple columns via table search on client-side data.
- Because of the above, the table needs fewer rows, so you can see header & footer on screen at once.

Description
=========
The existing Instances view will be split into two sections: Filter Section and Table Section. See pictures on Invision at http://invis.io/U21P372EA

The Filter Section will contain the the dropdown (Project, Host, Name, etc.) with text field and button, which is visually attached to the table today. The user uses the Filter Section to limit the number of items from the list API, so that the table has a client-side dataset of reasonable size. Subsequent BPs will build on the Filter Section; see the Invision link for a list of filter proposals.

The Table Section supports sorting, paging, and searching on all client-side data, not just the current page. The footer shows current position in data.

The client table will fetch the first page(s) of data from the API and display it quickly, and then load more data in the background. Sorting and filtering may not produce acceptable results until all the data is loaded. Since it takes time for the API to return instances, we should not assume we can load all the instances at scale; we should design for the data to overflow so that the user needs to filter it. Also, do we need to worry about overutilizing the Nova service?

ROW_LIMIT is the max number of items that the table will load client-side (500 in the pictures). This could be customizable by the end user in Settings, or might only be surfaced in local_settings.py.

The client must poll for the Status, Task, and Power State for all the client-side data, not just the current page. Otherwise the Status column could not be sorted.

There are two ways to implement the table: with jQuery or with AngularJS. With jQuery, we would use the tabesorter as in https://blueprints.launchpad.net/horizon/+spec/client-side-pagination. With AngularJS, we would use the Smart-Table. The jQuery tablesorter is quicker to implement from where we are today, but would need to be replaced later by an AngularJS implementation.

This BP focuses on the client-side design. A companion BP(s) will give the server-side design for the Horizon service to get the data from the Nova API and feeding it up to the client.

UX
===
Jeff Calcaterra to provide link.

Testing
======
Ensure filtering still works for each filter option.
Test filtering for items < ROW_LIMIT, items == ROW_LIMIT, items > ROW_LIMIT.
Ensure count information is accurate in all cases.
Test paging, sorting, searching - including i18n strings in different locales.

Outside Dependencies
==================
https://blueprints.launchpad.net/nova/+spec/server-count-api is required to get the total number of instances if it is greater than ROW_LIMIT. If this API is not available, we would use “500+” instead. (This is how we would handle Keystone tables.)

Requirements Update Required
========================
jQuery table (tablesorter) or Angular table (Smart-Table or other) must be available.

Doc Impact
=========
Document the new Settings field for “Items Per Table”.
Possibly document the behavior of the new filters--but hopefully it is self-explanatory, and stays out of the way until needed.

Specification URL (additional information):

None