Table next

[mever]

Dear Qooxdoo Community,

In https://github.com/qooxdoo/qooxdoo/issues/9302 I said I had my own table implementation. It turns out I am having a rough time porting/merging it into Qooxdoo. In particular keeping it backwards compatible with all possible use cases. Supporting APIs from which I am not sure if these are actually being used. Also, I am reusing what I can but can't help the need to refactor some interfaces.

Therefore I suggest to make a new table package. This way the burden of keeping BC stays low, resulting in more work done in less time. These are the milestones I am aiming for:

1. Initial package, not taking BC into account but also not needed (new package).
2. Feature parity, should be able to do (almost) all things {qx.ui.table} can.
3. And finally, aiming at a drop-in replacement.

So to clarify, I am not building a totally new table. I try to reuse as much as possible. The new package is to speed up the process and be able to show an intermediate result, e.g. the first milestone.

What does the community think? And if a new package is the way to go, what namespace to use, for example {qx.ui.table2} or {qx.ui.tbl}?

And while I'm at it. I know the current table is amazing. And the query 'https://github.com/qooxdoo/qooxdoo/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3AC%3Adesktop.table%20is%3Aopen%20' does not show much open issues. But I also like to hear if there are some fundamental issues I am missing, because now is the time to let me know.

[oetiker]

Hi @mever

there is another 'problem' with the whole table implementation ... the license ... it is one of the few remaining bits of QX which is still under GPL/EPL and not MIT like the rest ... so if you were to re-implement table, in a more modern way, with a compatible API, then this would be very cool indeed.

There was some work going on in creating a new table infrastructure in qx but it was never completed ... see http://www.qooxdoo.org/current/api/#qx.ui.virtual ... features like rows with non uniform height for example come to mind.

[johnspackman]

Actually +1 for a general, non-UI virtual framework to go behind something like this - we've discussed it somewhere before, but it would be great for a class derived from qx.data.Array that can load and unload on demand (which could then start to be used elsewhere)

[mever]

This blog post refers to a wiki which supposed to have all kinds of ideas, features and use cases: https://news.qooxdoo.org/infrastructure-for-virtual-widgets-call-for-ideas-b755b23aa1e7

Does anybody know where it is? I get a not found page.

Also, is there any additional documentation or UML diagrams besides API documentation about the infrastructure for virtual widgets?

[sbusch]

Latest working version of the "wiki" linked in this blog post: http://qooxdoo.org/documentation/general/virtualwidgets (archived by web.archive.org)

Printed to PDF: qooxdoo Infrastructure for Virtual Widgets.pdf