Lately I've been thinking about how UIs are built and ways to automate them. This came partly from my restart of the wordpic project (nice progress once I changed the goal posts a bit) and partly from looking for a cross-platform GUI toolkit and being frustrated a bit by the (lack of) options available.
This made me think of things like Rails scaffolding which will autogenerate a UI once a data model is specified. Everyone that I know doesnt use it in a production setting because the UIs generated are quite generic, and more importantly have a 1-1 mapping between the domain context and the view. For example, if you have a master-detail relationship, Rails scaffolding can get you a list of the master "rows" with a link to the detail as a separate page.
Regular (human built) applications dont work that way - usually the master is the top half of the screen and the detail (once a choice is made on the master list) is the bottom half. The orientation could change, but typically application views are "compound" in that they typically have multiple such correlated facets in the same screen or page. Is this something that can be autogenerated, though?
I think the answer is yes, and here are the rough sketches of the idea:
This made me think of things like Rails scaffolding which will autogenerate a UI once a data model is specified. Everyone that I know doesnt use it in a production setting because the UIs generated are quite generic, and more importantly have a 1-1 mapping between the domain context and the view. For example, if you have a master-detail relationship, Rails scaffolding can get you a list of the master "rows" with a link to the detail as a separate page.
Regular (human built) applications dont work that way - usually the master is the top half of the screen and the detail (once a choice is made on the master list) is the bottom half. The orientation could change, but typically application views are "compound" in that they typically have multiple such correlated facets in the same screen or page. Is this something that can be autogenerated, though?
I think the answer is yes, and here are the rough sketches of the idea:
- You start with a base set of data types you'd support: numbers, strings, dates are a good start.
- Define views and editors for each data type. Views are displays and editors are UI widgets that allow input of that data type and there could be multiple such views and editors for each data type. Nothing new here, except that the views are defined in terms of the data type.
- Define a compound data type as a collection of the base data types. Again, nothing new here, this is equivalent to a C record, Java Class, Ruby's ActiveRecord, SQL Table's row, etc.
- Define views and editors for compound data types as a composition of its constituent base types' views and editors. Thus the number of possible compound views and editors is the cross product of available base views and editors.
- The final compound view is chosen based constraints, the simplest of which might be a preference setting for one view over another, or one view/editor being the default.
- Collections of base or compound data types is another compound type that can have its own view (and editor). For example, a collection might be displayed as a horizontal or vertical list. Collections correspond to arrays, java collections, SQL Tables and so forth; and their views correspond to menus, lists, tables, tree tables, accordion displays and so forth.
- All views and editors are ultimately drawn onto viewports which may be smaller, equal or larger than the required total size. They can also be multi-viewports that map to multiple monitors or screens.
- Constraints:
- Function pipeline