Was: S.O.D.A. --> Relational GUI

Hmm... Some old articles resurfaced.

In article <Qpl67.14107$gj1.1452516_at_bgtnsc05-news.ops.worldnet.att.net>, Richard MacDonald says...
>
>I'd say GUI
>frameworks are where OO has done best; its the other stuff that's hard.
>IMHO,
>there is no argument that OO has triumphed with GUIs, but I would be willing
>to admit that the rest of the application is up for grabs.

As programmatic convenience of putting some nice abstractions and factoring ugly procedural calls with many arguments OO frameworks shine somewhat. In terms of forcing a programmer to navigate between widgets via pointers it's still far cry from relational.

>> Indeed, given an complex UI appication, why can't I ask to find all the
 combobox
>> widgets with a country list easily?
>
>Because no list widget should know it happens to be displaying "countries".
>(The application should know, though.) If 2-tier blending of application
>logic and
>gui displays taught us one thing, it was "don't do it".

In Allen Hollubs series of articles in javaworld separating gui and business logic is not a dogma any more.

In relational, the question where business logic is is less of importance. I just want to ask the system what widgets are responsible for displaying list of countries. I might want to find those on a single window, or in the whole application, or by some arbitrary business criteria.

>> I shipped this monster application last
>> month and customer wants to update country lists everywhere changing the
 "All"
>> option to blank entry. Please don't tell me "you have to reuse". No matter
 now
>> bad my implementation is, the request is so simple and it could be easily
>> formulated in -- guess what -- SQL. Some people like Peter Douglass in
>> comp.object already expressed an idea of having relational engine within
>> programming environment...
>
>That's a leap I cannot follow. Care to show how SQL will find all the
>widgets
>that display countries, then update their behavior to change the "all"
>option
>to blank entry? And if you're talking about storing the gui "schema" and
>"instances" in a relational database, then ok, but that's equivalent to
>using an
>O/R mapper to doing the same thing and having the same capabilities. Are you
>seriously suggesting we do this, or did I just miss your point?

It maybe just a terminology, but let's talk about Relational Access to GUI engine, not relational database, because the latter is usually associated with some storage on disks. First, we must establish the schema, and this is probably the most challeging part. My naive attempts to model anything that is realistic from GUI perspective ended up with very unnatural schemas. Nesting GUI widgets/layouts is the biggest problem of all. So I wouldn't try to fool your by just throwing a couple of tables ala Countries, Comboboxes, etc, and writing SQL statement. In short, if I knew how Relational GUI engine should work, I would be already busy implementing it. Received on Sun Jul 22 2001 - 03:53:19 CEST