[under construction]
The attribute and perhaps method grouping/sorting problem discussed in NodeJsAndHofGuiDiscussion suggests that TableOrientedProgramming could be used to manage GUI specifications.
I am going to present a draft GUI schema so that we have a reference set of structures to work with. Keep in mind that the actual tables don't have to be in a RDBMS to function as GUI-related tables, although it would be easier to use off-the-shelf tools such as a TableBrowser if one did.
It will generally be assumed that the table design is not language-specific so that it can be used by multiple languages. (A limitation with many GUI engines is that they are hard-wired to a given programming language.)
Languages-specific wrappers/API's can be created.
widget table
---------
widgetID
parentWgtID // container or "outer" widget. Zero for root.
wgtType // window, form, button, image, input-box, label, etc.
wgtTitle
wgtPosition // see [to be inserted]
wgtContent
wgtDefault // default content for new or reset widgets (including list default if applic.)
wgtStyle
widgetAttrib table (to roughly emulate DynamicRelational)
--------
widgetRef // foreign key to widget
attribName
attribValue
// primary key is widgetRef + attribName
eventListener table (may not be needed, depending on model)
---------
eventL_ID
nameSpace
guiObjRef // GUI object to watch
eventType // Type of event watched (click, double-click, etc.)
priority // 0 to 9
runObjRef // object name or address to run, depending on hook-up technique
runMethodRef
lists table // used for drop-down lists, etc. (if not bound to RDBMS table)
------------
listID
listValue
listDescript // by convention, listValue is displayed if listDescript not given
listSequence // double-precision
// primary key is listID + listValue
[more to come]
...
--top
Managing GUI specifications with TableOrientedProgramming is an interesting idea, one that harks back to the "data-driven development" movement that was popular in the 1980s. However, GUIs tend be edited in one of two ways:
- Via native code, either because the quantity of GUI editing -- maybe just a dialogue box here and there -- doesn't warrant external tools, or because we need the flexibility that native code affords.
- Via a WYSIWYG GUI painter, which inevitably generates code somewhere but we almost never have to look at it. Editing the GUI is by clicking, dragging, etc. on a "live" GUI.
Thus, I'm not sure where a TableBrowser would be useful.
I suppose I could see it being a useful adjunct to the Properties editor inside a WYSIWYG GUI painter, so that you could (for example) look at the titles of all the radiobuttons grouped together. That might be handy.
I agree that an off-the-shelf TableBrowser wouldn't handle a good many needs and that IDE integration is probably the best approach. If there are not a lot of fields or widgets, then markup is probably sufficient, at least for the non-coded parts, but if you are dealing with CRUD applications with gajillion fields, then to have the ability to sort, filter, etc. by various ad-hoc factors becomes very useful.