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.

No wonder you like OO. You have been around crappy procedural/relational programmers and don't know any better.

If you hang around dead humans, of course apes will seem smarter.

> It is impossible to enforce it in big
> application development team anyway

Why is that?

> (in extreme cases we are talking about 1000
> programmers:-). GUI schema starts playing the role of an application coding
> standart...
>

huh?

>
>

-T- Received on Mon Jul 23 2001 - 03:33:48 CEST