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

"Richard MacDonald" <macdonaldrj_at_att.net> wrote in message news:<7TK67.15377$gj1.1599296_at_bgtnsc05-news.ops.worldnet.att.net>...
> >
> > 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.

Disagree. Paraphrasing: "we'll just get some [arbitrary] physical implementation, and put relational interface upon it [make it nice logical model]". Also, SQL or not, reconciling nested widget structures with relational model requires some nontrivial effort. Received on Mon Jul 23 2001 - 18:37:52 CEST