Decouple the client form metadata on the server

[cristiano-belloni]

As a developer of an application that renders a Vuu table and switches between many groupBy + aggregations preset, I find my code coupled with the table schema in different ways:

Header names

When I receive table metadata on the client, I essentially get a map of column ids + column types. To map the column ids to actual table header names that the user can read, I need to maintain a map between column ids and header names on the client. Every time the server changes schema (renames, removes or adds a column), the client must update the header name map consequently. It would be of great help if the server had a mechanism to store header names alongside column ids and communicate the mapping to the client.

Data types

More granular data types

Right now, Vuu has a few data types - if I'm not wrong various numeric types and string. If the client needs to interpret the data types in a more granular way (for example, some columns with a numeric data type might be representing unix timestamps that need to be converted into dates, or some columns with string data type could represent URLs that need to be represented as links), it needs to maintain a map between column ids and formatters. Again, when the schema changes on the server (even a simple rename of a column id), the client needs to migrate accordingly. Having more granular data types could help covering most of the formatting cases. In some classes of applications, this would ideally remove the necessity of involving developers, pipelines and deployments in the process of adding presets, correcting wording or even customising UX (for example, developer could implement a library of cell renderers and UX experts could configure the application by storing the appropriate renderers in the custom metadata)

Custom data types / tags

In case the client has unique presentation needs that are not easily generalisable (for example, color-code some of the columns based on buy / sell status, render all the cells of a column as a series of tags, enable sorting or filtering only on some columns etc...), it would be of great help for whoever sets up the application to be able to optionally attach one (or more?) custom data type to each column on the Vuu side, that the client can receive and switch on to select the stylers / validators / formatters / renderers to apply without resorting to mapping column ids to list of formatters etc.
Theoretically, they could not even be data types, but generic "tags" attached to the column that the client can interpret.

View presets

In case the application has presets (for example, a static list of different groupings, column subsets and aggregations that the user can switch on by changing page in an SPA or selecting values from a dropdown), the client needs to store a series of configuration objects with direct references to column ids to pass to view when the user switches configuration. A server schema change is quite risky in this case; if the UI is not updated accordingly, it may risk requesting columns not present in the Vuu table schema, in which case Vuu will just close the connection. It would be of great help to be able to store view configurations on the Vuu server and refer to their names / ids on the client to get them back, with the safety of them being always up to date.

Admin tools

It would be very helpful to have a UI admin tool served by the Vuu instance to help configure / update all the metadata associated with a table. For example, the admin tool could be a drag & drop tool that validates presets against the existing column ids, and could be operated by non-developers to write a part of business logic.

[heswell]

I don't have much substance to add to the above, it's quite comprehensive. I agree with all.
As part of the work we'll be doing in preparation for version 1.0 of Vuu later this year, we are building out UI for data grid configuration. This is all client side and will allow users to select columns to be included in grid, formatting aspects of some of those columns (num of decimals etc) , custom renderers to be applied to columns.

This will all involve more of the same client side config described above, with the same issues of syncing with server implementation.

I like the tags idea for more precisely annotating column types . Bid and Ask for example might be tagged as price in addition to the basic double type. Then custom renderers can be registered against those tags on the client, so any column tagged as a price might offer the "Flashing BG' custom price renderer.

We could potentially make the UI that we build for end-user configuration of local settings also serve as an admin tool for maintaining the serverside default settings.

[cristiano-belloni]

Yeah, I guess you can have a taxonomy of pre-canned keys / tags. It'd be still good for it to be extensible somehow, though. I can think of some cases not captured by those broad categories: event handlers on various actions, fdc3 context sent when a cell in the column is interacted with, max, min and initial width of the column.

[cristiano-belloni]

Surely you can support all of them, or even emulate some of them with renderer, but if users need to get hacky to support their use case, why not give them the ability to extend schema?

[cristiano-belloni]

The Fdc3 spec is actually a good model: it gives you default contexts that cover 90% of the use case but lets you specify your own contexts. I think it works.

[chrisjstevo]

Can you ping over a link? I will review. Thanks.

[cristiano-belloni]

FDC3 has pre-cooked standard context types but let you specify any type you want. Typically big organisations use their own types for any custom context that is not captured by the standard ones. A good example of Pareto principle.