This tool is about showing table information in a usable form. Initially we found that on most of our projects users would like themselves to choose which columns they will get in the tables, that they see on the screen. Since databases are usually relational, it is common thing that users want related data to be displayed as well, and want it to be displayed despite the kind of relation (1:M, M:1 or M:M).
Another demands were:

  • row filters, so that user can filter out those rows that he needs
  • performance, so that if user chooses less columns or less rows – he should wait less
  • security, so that each table should have piece of code which will define what columns and what rows should be visible for this particular user
  • ability to make view configurations persistent and share view configurations among users
  • for those reports that group rows (e.g. sales by manager) – to be able to ungroup rows in order to see what data was grouped by this report.
  • this mechanism should be able to manage millions of records

As a result we have built flexible component which have follwing key features:

  • each DB table or another data source has description of its visible columns, applicable filters, security options (what columns and what rows are displayed), order options, etc. If a table is accessed as a relation, then there is no need to specify all these again. This work in the similar manner as in most ORMs, but our component is optimized for processing many records, instead of lazy loading and similar things.
  • user is able to choose columns which he wants to see, drilling down through all kind of relations (1:M, M:1, M:M, 1:1) accrding to user’s permissions
  • user is able to filter rows and specify ordering
  • user is able to configure width of columns, limit number of characters in particular cells, apply totals at the end of table
  • user is able to save his favorite configurations and switch between them in one click
  • user is able to share his favorite configurations among other users
  • where allowed user is able to perform in-table edit by clicking on the value and changing it. When user confirms his change the AJAX call is delivered to appropriate callback in the model layer.
  • of course there is export to spreadsheet file for futher proccessing.

From development point of view the key goal was minimizing amount of code of application. For example you have a report “sales by manager”, which has totals grouped by manager. Our idea is that user should be able to get source ungrouped information without any extra line of code written in the application. But of course grouping should be applied by database engine for performance.