[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.