Add table widget example

[damienflament]

A TableWidget to display tabular data.

• [x] Add exported names to the widgets module
• [x] Module, classes and members documentation
• [x] UIExample in the module documentation
• [x] Style
• [x] flex support like HBox layout for TableRow
• ~~Allow to horizontally align TableCells content like in a spreadsheet~~
• ~~Allow to add other widgets in table cells (to display links or buttons)~~
• ~~Allow to sort entries by attribute using header cells~~

[damienflament]

I choose to use the words entry and attribute instead of row and cell to make it related to the data shown in the table instead of the table structure.

Any comment about that ?

[almarklein]

This could be a really nice widget!

Though we should think well about its intended purpose. The way that it works now (with widgets even for individual cells) might make this widget potentially "heavy". Whereas I expect that users will put a handful of cells in the new GridLayout, I can imagine that a table can be used for potentially hundreds of rows. Therefore, I think that the data can best be expressed as a single property (a list of lists). An API to manage the rows in the table without having to reset the whole table, with actions like (add_row, insert_row(), delete_row() would be really nice. Also being able to sort the columns would be awesome :)

I think I'd prefer the terminology of row, column and cell because it is what most users will be familiar with.

[damienflament]

I tried to mimic the TreeWidget interface to keep consistent. I see this widget as a tool to build an UI without connection with the data model. Then, the view (the user class inheriting Widget) holds a reference to the model and builds the UI using widgets.

That's why I was talking about DataWidget earlier. I see it as a high-level widget handling data internally, maybe inheriting the new PyWidget component.

[almarklein]

It indeed reminded my of the TreeWidget :) But I am not entirely sure whether it's a good idea. (It can also be argued if the treewidget should better have used a list to indicate its rows.)

I'm not sure I follow. I think what would make the most sense is a data-oriented widget. Something that can efficiently display tabular data, and which can scale to many rows. As an example have a look at the DataGrid widget of PhosphorJS: http://phosphorjs.github.io/examples/datagrid/ That one seems to separate view and model, making it possible to generate data on the fly (and thus showing a "table with trillion rows", or streaming rows). Does this look similar to what you had in mind?

[damienflament]

It depends on the way you want to design your library.

For now, I see only widgets generating HTML markup with minimal CSS to provide a simple unthemed UI based on the FlexBox layout. It's simple and efficient (I personally dislike tools generating a lot of markup). That's why I chose to give a try to Flexx.

But I don't negate the need of a widget to display a lot of tabular data. I think about it as a component based on PyWidget, because of the lack of features supported by PScript (e.g. I failed to create a date object in the TableWidget example). Moreover, I think processing data using Python and displaying it using JavaScript is a good approach (it is also the approach of Flexx; am I wrong ?).

But to make this kind of widget, I think we must start by defining a data model API and a data widget API. Then, we can create a data table widget, which can use the TableWidget API instead of playing with the DOM directly.

It's up to you. If my current implementation does not follow your needs, I can close this PR and use it in my project. Maybe later I will need a widget to display a lot of data, I will try to implement it and make a new PR. :wink:

[almarklein]

The core set of widgets provided by flexx.ui should represent common and clear use-cases. I think there would be room for a data-oriented table widget, but I also now realize that such a widget needs careful design for its API and implementation. I don't know what it should look like yet, to be honest, and I suspect that what you have in mind is slightly different.

That does not mean that what you're making here cannot be useful to others. I think the best approach for now is to implement this as an example widget in the flexxamples subpackage. This way, people with similar needs can re-use your code (all widgets in the flexxamples subpackage can be imported!).

[h5rdly]

If I may offer opinion as a user, to me the usecase is streaming pandas dataframes / python dictionaries into the table, so I could really benefit from a "classic" table, with flexible selection of coloring or highlighting by cell / column / row. A table of widgets sounds like another way of implementing some sort of grid layout

[h5rdly]

Sweet progress. Is this going into 0.8?

[almarklein]

@damienflament is this about ready for merge?

[damienflament]

I tried to implement sorting using third-party JS libraries, but I don't know where to initialize it. Within _create_dom and _render_dom, TableWidget children are not created yet.

[almarklein]

Why a 3d party lib? Lists (JS arrays) suport .sort(), including .sort(key=lambda x: ...). I think you'd need it in _render_dom.

[matkuki]

Is this widget still being added? It would be a marvelous addition!

[almarklein]

I'm still of the opinion that if we are to add a TableWidget to flexx.ui.widgets that it should follow a more "data oriented" approach, instead of having one widget for each cell.

That does not mean that this code is not useful. As I mentioned earlier, this code would be a great example (in the flexxamples subpackage). This would also mean that other users can import and use the widget.

[gwingnhbc]

The way that it works now (with widgets even for individual cells) might make this widget potentially "heavy". Whereas I expect that users will put a handful of cells in the new GridLayout, I can imagine that a table can be used for potentially hundreds of rows. Therefore, I think that the data can best be expressed as a single property (a list of lists). An API to manage the rows in the table without having to reset the whole table, with actions like (add_row, insert_row(), delete_row() would be really nice. Also being able to sort the columns would be awesome :)

I can confirm this :-) My application includes rows of widgets constructed from data and essentially renders instantaneously for the typical 20 or so rows expected in use. However with a test data set of 500 rows it really lags rendering the layout and throws 'script not responding' warnings in the browser.

I think there may be two distinct use cases, one being to render large numbers of display items in a table and the other being to actually render functional widgets in a table format. I rather doubt if there is a single elegant solution that would cover both of these.

[matkuki]

Is there a hack that could be applied to this table widget to make it usable for large numbers of rows/columns?

[almarklein]

Is there a hack that could be applied to this table widget to make it usable for large numbers of rows/columns?

I think what would be needed to be able to display a large amount of rows/cols, the widget should not use widgets for rows and cells, but use <table> instead.

[h5rdly]

Is there a hack that could be applied to this table widget to make it usable for large numbers of rows/columns?

I think what would be needed to be able to display a large amount of rows/cols, the widget should not use widgets for rows and cells, but use <table> instead.

Is this something that could be added to this Widget, or do you think this is requires a new DataTable widget?

[almarklein]

Is there a hack that could be applied to this table widget to make it usable for large numbers of rows/columns?

I think what would be needed to be able to display a large amount of rows/cols, the widget should not use widgets for rows and cells, but use <table> instead.

Is this something that could be added to this Widget, or do you think this is requires a new DataTable widget?

That would be a new widget.

[h5rdly]

What's the damage of implementing it? I'm this specific widget away from building a DB-API 2.0 SQL Editor based on flexx (TreeView and MultiLineEdit are others I needed)

[almarklein]

What's the damage of implementing it?

Sorry, what do you mean with "damage"?