Re: [T] 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.

I question this also. Table driven GUI's would not need to pass around lots of parameters as TOP encourages attributes to be in tables, not function calls. It is the static, RAM-centric procedural thinking that has this problem.

I agree that a table-oriented GUI systems are not common, but that does not mean that they are not feasible.

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

A good table system will buffer stuff in RAM if frequently-accessed. The idea that Tables==disk is outdated.

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

What kind of nesting? Panels?
Use a ParentID.

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

If it was in something like this:

http://www.geocities.com/tablizer/ddsamp.htm

It would be easy to isolate them all.
(How easy it would be to edit them all
depends on the repetition-factoring skills of the original programmer, procedural or relational. A decent procedural programmer would put most of the country-list stuff in a shared subroutine, Thus, changing the default should be in one place ideally.)

>
>

-T- Received on Sun Jul 22 2001 - 09:11:34 CEST