Re: [T] S.O.D.A. --> Relational GUI

In article <MPG.15c41e3c99a27d2a989bfb_at_news.earthlink.net>, Topmind says...
>
>> 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 noticed improvements on your site, but still fail to understand how TOP works.

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

You mean GUI that is limited by tables only? Please be more specific what end user sees, and what GUI designer/programmer does.

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

Layouts. I need to describe that widget A is positioned in left right corner relatively to B. (Here we touch the subject of spatial databases, did you notice?-)

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

Ok. You show a designer-time table that describes the attributes of GUI table that end user sees. I am assuming that each row in your design table describes a column in the GUI table. How do you access the data that will fill in end-user table? SQL, or something else? Where the access path is stored in your model?

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

No, the relational approach doesn't require any code refactoring/code organizational skills from the programmer. It is impossible to enforce it in big application development team anyway (in extreme cases we are talking about 1000 programmers:-). GUI schema starts playing the role of an application coding standart... Received on Sun Jul 22 2001 - 20:17:25 CEST