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

"Mikito Harakiri" <nospam_at_newsranger.com> wrote in message news:jmq67.2615$ar1.6451_at_www.newsranger.com...
>
> >> 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.

The comp.object group discussed those articles and agreed he had some sort of temporary insanity.

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

Ok, it just took me a while to realize you were thinking of a relational schema for
GUI widgets and representing an application's GUI in these tables.

I don't see why this would be so hard to do. Its pretty easy to take a good existing
GUI framework and simply map its attributes via an O/R mapper. That would be a good starting point and would satisfy your SQL query desires. Sure, SQL isn't going to be able to handle the nested guis (the BOM problem) though. Received on Mon Jul 23 2001 - 03:13:39 CEST