Table Oriented Gui Discussion
Table Oriented Gui DiscussionThis is about implementing a GUI engine using tables rather than focusing on the display and editing of tables themselves (TableBrowser).
Discussion moved from ObjectiveEvidenceAgainstTopDiscussion
Well RDBMS is not doing so well in the GUI department (OOP seems to suit GUI widgets more). So RDBMS is limited to certain applications. However, a lot of applications deal with data, and people often use IniFile, XML, stringlists, associative arrays, dictionaries, not RDBMS. So RDBMS indeed suits a lot of applications that we currently don't use it for. It's mostly because sending SQL strings and setting up the DB takes too much work and is too inconvenient for the customer. So the relational language needs to be built into our existing languages, in addition to having a language we can send by string, like SQL.
That's why I'd like to see DynamicRelational in action. The existing flavor of RDBMS is too "rigid" and "static" for some uses. We got both "strict" app languages and "scripty" app languages, why not something similar on the database side? -t
It's really got nothing to do with being Dynamic. One can still have a static strong typed RAD tool, so you could still have a RAD database tool inside your language - instead of STRUCTS and ARRAYS in CeeLanguage, you would have TABLES. Instead of just IF, WHILE, and GOTO, you would now have relational reserved words such as WHERE, SELECT, FROM, etc. There are many rigid strong typed RAD tools like Delphi, so why can't there be rigid data tools that are still RAD. Of course there can be.
Does Delphi tablize the GUI? That's the issue, not the existence of a GUI tool, if I am not mistaken.
Your claim was that we need something more dynamic and scripty. My claim is that it's got NOTHING to do with being scripty or dynamic: if it had something to do with being scripty or dynamic, why are the visual rad gui tools like delphi not scripty and dynamic?
It was in response to: "Well RDBMS is not doing so well in the GUI department (OOP seems to suit GUI widgets more)". Delphi uses OOP to manage GUI's, not tables, if I am not mistaken. -t
But your claim was that you'd like to see dynamic relational in action. What is stopping someone from taking delphi's records/classes and turning them into strongly typed tables? Where is your objective evidence that "dynamic" is better, and that scripty is better for GUI? I've thought about using tables for GUI and it doesn't offer the benefits of inheritance unless you reinvent inheritance in the database, so you end up using OOP ultimately even if you use tables. Scripty is often NOT used for GUI - php, python, ruby, all dynamic languages that are rarely used for GUI. So where is your objective evidence that they are better for GUI? I'd even argue that Records/Structs/Classes are actually a MinimalTable itself.. just that they don't have all the relational capabilities like SELECT FROM and WHERE. A struct in CeeLanguage is so strikingly similar to a table row or tuple, that it's not even funny. So you could take visual C++ and turn it's strongly typed structs/classes into tables too.
There are a lot of issues raised in that paragraph. It was not me who suggested that OOP is better than tables for GUI's. That's the person who has an obligation to justify betterment. At this point let's just "look at" the tradeoffs rather than try to judge a summary winner.
As far as inheritance, tree taxonomies are too limited for GUI's for the same reasons they are limited in other domains: insufficient feature combination control (LimitsOfHierarchies). I'd instead suggest a GodGuiWidget, and then use switches and attributes and views to turn various features on or off. HAS-A instead of IS-A. Hard-carving widgets into a taxonomy of say hyperlinks versus buttons versus click-able images limits one's options. They are too similar and potentially interchangable. I won't do that up front unless there is a solid reason. -t
{As someone who spent over twenty years developing proprietary UI widget toolkits, I find this page... Interesting. Top, please, please, please, please try to implement this. If you code nothing else, ever, you have got to work on this. You will learn things you haven't imagined.}
I assume you mean I will likely encounter unanticipated difficult problems. I suggest you point out some of the more interesting and telling lessons you learned.
{No, no. You'll probably want to quibble, and you won't learn much. For example, here's a lesson: "For creating, using, and extending UI widgets, OO works really well." Do you feel like quibbling? If so, don't. Go try coding it with tables instead.}
Define "extend". Sometimes vast experience with a single paradigm boxes in one's thinking. (My suggested approach was probably too hardware intensive in 90's, but may be viable soon.)
{See? You're quibbling. Stop it and go code now.}
I generally study a variety of scenarios against a draft (dummy) language first, and THEN code. Perhaps Rel wouldn't suck if they did this publicly. Just present a scenario that shows OOP's "inheritance" superior to a TOgui.
{How can I? You haven't written your TOgui for me to compare with. "Perhaps Rel wouldn't suck if..." Huh? What does that have to do with this?}
See LearningWithoutImplementation.
{How can I compare OOP against something that isn't even defined, let alone implemented? You're asking me to compare horses with heffalumps.}
Then how do you "know" tables suck for GUI's?
{Where did I say I "know" tables suck for GUIs? For all I know, they don't. All I said was that you have got to work on your TOgui. You will learn things you haven't imagined. And I said "For creating, using, and extending UI widgets, OO works really well." That's true. It doesn't mean a TOgui wouldn't work well. It might. Please try to show us.}
I vaguely remember an existing long discussion about "extending widgets" in a non-OOP GUI framework about 2 years ago. But I can't find it right now. The scenario of a custom dial widget came up (IIRC) and how it would "upload" over the network and be used in multiple app languages.
Thanks! Some of the limitations mentioned are due more to having a GUI engine that can be used with multiple programming languages without lots of language compiler/interpreter changes. OOP-based GUI's tend to hard-wire the engine and conventions to a particular language, which limits our options and scope.
{Next week, I'm going to show a room full of final-year computer science students how to create OOP-based language-neutral libraries. In the mean time, please start working on your TOgui.}
If you do it well, you'll be one of the first. Your Nobel Prize awaits. (I hope it doesn't suck as much SOAP.)
For object compatibility there is also CORBA and COM - some argue corba is so complex that not many want to use it. COM is criticized as a microsoft technology, and complex. Although it is a microsoft technology, they had some plans to implement COM on unix, or they did implement it but it was not widely used - I'm not sure. This page has some information on Active Group/Open Group and activex/corba: http://www.omg.org/library/activex.html
Why not make it XML-based? Something like GuiMarkupProposal.
{You mean... Like SOAP?} (SimpleObjectAccessProtocol)
Where's an example of a SOAP GUI XML language? I saw no GUI-oriented ones in those lists. I suspect the SOAP aspects will bloat it up with repetitive formality.
{I was referring to the XML-based-ness.}
The topic is GUI's.
{I know. I was referring to the XML-based-ness.}
Well one reason why Structs in Cee (and classes) are still used instead of tables, for gui's, is that GUI's rarely have thousands of widgets that you need to access relationally on your screen. A window has a few widgets on it and that is all. Once in a while I create a GUI application that has hundreds of widgets on it, and once in a while I need to find the widget (search for it), but this is rare. A typical dialog box has an OK and CANCEL button along with a few edit boxes. Why would I need relational access to these buttons? they can just be Cee structs or classes, I need not access them relationally. Still, even saying this, structs are similar enough to rows/tables that I think that a table oriented gui would be possible - but worthwhile? I'm not sure.
I've thought about table oriented gui ideas for years. One advantage of a table oriented GUI, or a database oriented GUI, is you could save your widgets (persistence). People use files to save their widgets screen positions, reinventing the database. Like in delphi you have DFM files which save the form data - this DFM file is a miniature database of sorts, that you can't access relationally - it's just a text file. Would you need to access it relationally? not usually - in rare cases it could be handy.
Another advantage of objects or structs and procedures, is that they are more free form and flexible than tables... Tables enforce a boxy shape, whereas objects can have different shapes. This free form nature of objects makes them prone to abuse too, whereas tables are more bondage and discipline (enforces it to be shaped very boxy). Possibly I am using informal crankpot terminology here but I hope you understand what I mean. An object can have sub objects, sub records, sub structs, pointers to other things, methods, it is very flexible and free form. This can be a double edged sword - it allows for much creativity, but also for much abuse.
The rigidity is why I mentioned DynamicRelational above. I don't believe the rigidity to be an inherent feature of relational, rather a flavor of relational as influenced by Oracle and IBM's early models.
Another reason to consider database-ness is because databases have better solutions and existing infrastructure for cross-language AND networking usage than per-language API's. Related: CrossToolTypeAndObjectSharing.
Well if you have a button in VB 6, it isn't compatible with a Delphi button because they have different property names. A button color may be called "btnColor" in VB, whereas in delphi it could be called "buttonColor" or "color". Whether you store it in a database, or XML, or DFM file doesn't change the fact that VB widgets may have different attribute/property names. In Java they don't have properties, they have Set() and Get() functions (setColor, getColor), so there still exist incompatibilities if you use a database. People would have to settle on a common widget set with common widget properties/attributes which is kind of a PipeDream. It would kind of be a centrally planned communist single widget set which might form a monopoly (but it might also be something like GTK or QT). I suppose Ms COM was a PipeDream too but it sort of succeeded with certain gotchyas.
Naming and set/gets is the least of the difference problems. I propose the GUI engine be developed independent of a given app language. It should be possible (for testing and debugging) to issue it commands, such as query commands or XML from a command prompt and see the changes in the GUI arrangement. One could also "x-ray" and/or log the "conversation" between the GUI engine and the application. Thus, if I type "curWindow.button7.color='blue';" in the "GUI console", then the color of button 7 changes to blue in the GUI. (Dummy sample command for illustrative purpose only. Syntax will probably differ.) Tk and to a lessor extent the HtmlStack are probably the closest there has been to a cross-app-language GUI "engine". (X-Windows is too low-level.)
XML widgets or widget configurations in a database still leave the actual implementation of the widgets to be coded. I.e. are you going to use object orientation in Firefox to display HTML widgets, or are you going to use Cee structs, or can you use tables with code that queries the tables? What I vision is Cee structs being replaced with tables possibly. On the other hand cee structs are GoodEnough and maybe tables are overkill, or maybe tables are too rigid and cee structs are more flexible. Also drawing widgets on the screen is still either procedural or object oriented.. the table just seems to store the data, whereas the actual code/logic still needs to be written using procedures or object methods. If you type curWindow.button7, isn't this object oriented? The button7 is located on the curWindow object. Call it an object, or structure, or whatever - but isn't it smelling like object orientation to you?
Please describe an example of the kind of rigidity you are envisioning, including with DynamicRelational available.
I envision a brand new GUI Browser or add-on that does GUI's right and doesn't try to carry the baggage of prior attempts. It would be roughly comparable to Flash and Java applets as far as the distribution model.
Re: "whereas the actual code/logic still needs to be written using procedures or object methods." - Do you mean application-specific logic or the implementation of the Gui Browser? The goal would be to make the vast majority of common GUI behavior be declarative via setting attributes, including common events. For example, bringing up (launching or putting into focus) page X when button Y is clicked shouldn't require explicit programming: it's an event behavior commodity. Build it in! A scripting language, perhaps JavaScript could handle those the standard declarative part can't handle, perhaps with the option of "pluggins" for fancier behavior or widgets beyond what JS is practical doing. Keep in mind that a lot of the logic could still happen server-side.
I thought java script and CSS and HTML were sort of class/object oriented... what I'm trying to point out to you, is that you still end up using object orientation, even if you are also using tables too. When you reference things like curWindow.button7 in your XML or javascript, aren't you dealing with objects and not tables? Just because something is declarative doesn't make it non-oop. A truly table oriented GUI wouldn't reference things like "curWindow.button7" you would do something like "SELECT button7 FROM curWindow" which is too verbose and doesn't offer advantages of object orientation (oop offers more terse syntax ShouldRelationalBeMoreTerse)... and the button7 may not be in the curWindow table, it may be in some other table depending on what it relates to. This AhaMoment is when you discover not everything can be table-ized and/or that trees/objects might be better for some things. Put it another way: isn't curWindow.button7 a tree? button7 branches off from the main curWindow trunk.
The "button7" example was not meant to be a real language. I simply used it for familiarity to a typical reader. But in general, I expect less need to be "pathy" as far as referencing widgets, in part because of IDE's, and in part because of direct widget ID's instead of paths. This also allows widgets to be moved without re-stringing paths. It's similar to the reason we use employee numbers instead of "microSquish.IT_dept.bill_gates". Path-centric functions would be available for the few times when needed, such as getWidgetId("formName.widgetName").
Windows Api uses handles.. but often a descriptive english like name for something is handy:
mainWindow.closeButton.setColor('red');
I'd like to see someone do this relationally... it seems almost impossible since relational doesn't have Methods or Procedures. If using declarative programming like XML, you can't program the above setColor procedure without modifying the actual XML and reparsing it, or using some kludge like javascript - which is OOP....
{How about:}
UPDATE Gui WHERE Window = 'mainWindow' AND Widget = 'closeButton' SET Color = 'Red';But:
UPDATE Gui WHERE WidgetID=$targetID SET Color = 'Red';Is even more compact. Further, in the GodGuiWidget model, a window is just a "kind of" (variation of a) widget. The relationship between "window" and "widget" would thus be reference-based (perhaps with a Parent_ID) rather than hard-wired into a table. This gives more flexibility. For simple GUI's, the hard-wiring makes sense, but not for advanced/complex ones.
{Oh dear. I meant it as a joke.}
As described in GodGuiWidget, there would not be a separate table per object "kind" (window, panel, button, etc.) That's too inflexible. A panel in one context should be able to be treated like a widget in another, responding to the same events (if applicable) for example. In other words, uniformity in treatment.
As far as why try a table-oriented GUI? First, you don't know until you try. Horses were considered "good enough" for transportation once. You don't move forward if you are satisfied with "good enough". Second, OOP has mostly failed at cross-language GUI engine sharing, unlike RDBMS. -t
HTML is an example of cross language cross platform GUI tool - and with CSS html smells like OOP. You can reference each widget like you do in OOP - widgets in HTML have classes and the CSS file is very object orientation smelling.. Could you store the CSS file inside a table instead of the css being in a flat file? Maybe. Worthwhile? dunno. Why fix something that isn't broken. Well actually, in my opinion javascript and html suck, but they get the job done sometimes GoodEnough. Html is both document and object oriented in nature - I don't see much table orientation in it.
Most try to "configure" a given GUI via markup code and IDE's, not direct JavaScript assignments. Plus, I see a lot of "getElementById" calls in production JS, which is more of a relational flavor.
Ugh, get element by ID could be considered "pointer centric" since a pointer is a number pointing to something.. This is why I don't get your argument about narrow tables being pointer centric - yet you want to use pointers like employee ID or widget ID which is just a number that points to something else, LOL.
And I do think the HtmlStack sucks. It's had almost 15 years to get its act together, but is still arcane, unstable, version-sensitive, and flickery. At least the industry should have a back-up alternative in the (likely) case that the HtmlStack will continue to suck.
{As usual, you're going to have to write it, because it looks like nobody's going to write it for you.}
I'd rather see/make GuiMarkupProposal first.
Markup languages don't solve the problem of beyond the markup (i.e. javascript is beyond markup). Declarative markup based gui's are castrated, they need some power added to them in order to be used for anything non trivial. With HTML we either use javascript, or server side modification of the HTML after a request. All this reeks of mixing OOP with tables and trees to me. That's not really table oriented, it's more like tree/table/OOP mixtures. I don't think what you are proposing is a Table Oriented GUI, rather what you are proposing is a document/table/tree/OOP oriented mixed gui that has some of its configuration in tables.
I didn't exclude the use of scripts and/or execution of routines. And it doesn't have to be either/or: the underlying engine could be table-based, but most interaction from the app developer would be via XML, at least for the initial setup. If I'm debugging a complex GUI and events, I'd much rather explore the GUI config with a query language and a TableBrowser than an ObjectBrowser. When you get past a certain volume of data, OOP just sucks. Databases were meant to help manage large volumes of data and so are better prepared for it. (One could improve OO for such, but it would be a case of GreencoddsTenthRuleOfProgramming.) -t
The XML that you are using is not accessible relationally so you are going to use a tree browser or object browser to access the XML file, LOL. As your XML files get larger and you have more GUI apps, you will have a hard time finding stuff in your xml files... why are you storing stuff in xml trees when it could be in tables? What is the criteria for storing stuff in trees? Which stuff is stored in the xml trees and which in the tables? When you get past a certain volume of data, XML just sucks - so why are you using XML? You say the config of the GUI is in tables and that you will be able to query it - what about the config located in the XML files? that's not query-able, it's going to require an XML tree viewer.
Mr. LOL, I'm not sure what you mean by "not accessible relationally". I generally suggest XML and tables to be inter-changable representations of the same thing (although I didn't optimize GuiMarkupProposal for such).
What exactly is going to be inside the XML file if your configuration of the GUI is in the tables? Does the XML file duplicate what is already in the tables and does it map to the tables? Or does the xml file contain data that is not inside the tables? Does the XMl contain widget ID's that talk to the tables and gather further info? You're mixing trees and tables. XML files are not CSV files - xml files are trees. I consider CSV to be interchangable with tables, not XML. You can map something to xml, but it isn't a direct conversion like how csv is a direct conversion to a table. XML is trees, whereas CSV is not trees. I think you are using trees because your tables limit your brain, and XML is an escape out of tables into the tree universe. This use of XML is a way to escape the rigidity of tables. You've picked XML because tables stopped you from doing something? Otherwise there would be no xml, you'd have just use tables and csv, right? I don't even understand what you are using XML for if the configuration is already stored in tables? The xml configures something else? Or the XML maps to your tables (XmlRelationalMapper? like an OO relational Mapper?) Or the xml contains additional information not inside the tables? Either way, if XML is being used, you are mixing trees and tables, hence it isn't table oriented.. it's tree and table oriented!
Different people want different formats and I'm not going to dictate to them what is the "right" format. I'm not an absolutionist. Cater to different WetWare.
People have been hand-coding in HTML for more than a decade and expect to be able to hand-code a GUI setup in something similar. I generally picture the XML being the "starting" GUI description. The running version would be in tables.
And I still don't know what you mean by "rigidity" of tables, or if DynamicRelational would solve your perceived problems.
Structs in Cee allow trees, tables don't. Tables have a specific rigid square structure. Dynamic doesn't solve anything unless dynamic allows trees and the flexibility of a struct. If it allows trees and the flexibility of a struct, I'm afraid that isn't relational - that's something else entirely. With structs you can put a sub struct inside a struct, and you can have pointers. Relational doesn't offer pointers or subtables or trees - structs allow this flexibility. This flexibility is a double edged sword - it allows much creativity - almost too much creativity. I don't understand why someone would use XML (trees) for a table oriented gui - trees have got almost nothing to do with tables so it's an odd paradox happening. What I think is going on here is that you actually find XML more human friendly than tables because tables are rigid boxes whereas XML is a unrigid open document waiting to be typed up, just like an HTML page.
See RelationalAndTrees. What's an example of "greater flexibility"? As far as whether I find XML or tables more "human friendly", well ItDepends. It's good to have alternative ways to view and study the same thing and flip between them as needed. Tables are just a better "root structure" in my opinion because they are reasonably flexible and intuitive. Trees are more intuitive, but less flexible. EssExpressions are very flexible but not intuitive on a large scale (to most). Tables are the best balance in my opinion.
Imagine this: you start a website and you make a CSV file in a text editor. The CSV table is your website. Everything you put in the CSV file dictates the website design. Instead of using CSV, using HTML is easier because it is a document and a tree, not a square table. If you store the data both in the database and the XML file, you are duplicating the data. So are you going to have the XML file save itself to the database and store the data in both the XML and the database? Or is some of the data going to be in the XML, while other data will be in tables in the database? You could have a widget reference in the XML file such as "12345" and then this 12345 number could relate to data in the database. I'm trying to get a visual picture of what data you are storing in the database, and what data you are storing in the XML. Imagine an HTML document with BOLD and ITALIC tags. Are these bold and italic tags stored just in the html file, or are they also in the database too? If the bold and italic tag are not in the database and only exist in the html/xml, then this means that you are not mapping everything to tables, some of your markup exists only in the document/tree and other data exists in the table. What is a bold and italic tag inside a table? is it a cell? column? Is the bold tag not worth storing relationally whereas something like a DIV box is relationally worth storing?
If you have a content paragraph, say a story about the company picnic, that paragraph would likely be stored in the database, perhaps as markup text. One wouldn't normally hand-edit content such as a picnic story as markup if they had decent front-end tools for content creators. I'm assuming that content creation is a different issue than GUI layout development and will usually be handled by different kinds of tools. When hand-coding HTML pages, people will often blur the distinction, but more advanced tools won't.
Let's try to find a scenario that's in-between. Say we have a data entry CRUD screen with message at the bottom something like, "REMINDER: Don't forget to ask the caller if they want to upgrade to the premium edition." The word "REMINDER" is in bold. Our GUI system would likely treat that as a (non-editable) text area. A tabular representation would probably have a Value field or Content field for that text area widget, and the value of that Content field may indeed have markup in it, such as bold and italics.
Markup Version:
.
<text name="mytx" editable="no">
<b>REMINDER:</b> Don't forget to ask the caller if...
</text>
.
Tabular Version:
.
widgetID...widgetType...widgetName...editable...content....
-----------------------------------------------------
374........text.........mytx.........no.........<b>REMINDER<b> Don't forget...
(Dots to prevent TabMunging)
Note that an XML version of the GUI may have convenient and/or XML-author-friendly shortcuts for common patterns. For example, I rejected the idea of hard-wiring widget classification into the table schema for flexibility purposes. However, an XML version may still have tags for specific widget "types" as shortcuts.
"Flat" Version:
<widget id=7 type="panel" name="panel01" ... />
<widget id=8 type="textbox" parentwidget="panel01" sequence=1 ... />
<widget id=9 type="textbox" parentwidget="panel01" sequence=2 ... />
"Friendly" Version:
<panel name="panel01" ... >
<textbox ... />
<textbox ... />
</panel>
Both these would produce the same GUI. I'm assuming widget names cannot start with a digit such that references can be by ID or by name without the risk of a name overlapping an ID. In the database, the second would indicate nested-ness via ID numbers "parentwidget" instead of name if a name is not given for the container widget. To better handle larger GUI's, some kind of name-space management technique, including a "namespace" tag, may be needed to avoid cross-module naming conflicts for widget names. In the "old days", a window or document is generally used for such, but that's not flexible enough for heavier coding/config sharing in my opinion.
Perhaps a "namespace" attribute is assumed for every widget. A blank namespace is equivalent to "default".
<widget parentwidget="bar" ... /> // assumed parent "full" address (name): "default::bar"
<widget namespace="foo" parentwidget="bar" ... /> // assumed parent address: "foo::bar"
<widget namespace="foo" parentwidget="blah::bar" ... /> // assumed parent address: "blah::bar"
<guiNamespace namespace="buzz">
<widget parentwidget="bar" name="mip" ... /> // assumed parent address: "buzz::bar"
// assumed self address: buzz::mip
<widget namespace="foo" parentwidget="bar" ... /> // assumed parent address: "foo::bar"
<widget namespace="foo" parentwidget="blah::bar" ... /> // assumed parent address: "blah::bar"
</guiNamespace>
(Comment syntax not meant to be part of actual XML. It's just to make the illustration compact.)
See NonOopGuiMethodologies and GodGuiWidget for some sample or draft GUI schemas. See Also: AddressingGuiElements, DeclarativeGui, RelationalGuiDilemma
EditText of this page
(last edited August 27, 2014)
or FindPage with title or text search