workaround for generating gui tools

[flupke]

Jeremy Bowers wrote:

<snip>

> 
> Domain-specific abstractions do that *faster* than GUI designers, not
> slower. And better, too, since every iteration tends to be fully
> functional and not just a "let's see what this looks like" prototype.
> 
> Heck, switch 'em out dynamically based on what day of the week it is and
> how the user feels today. Let's see your GUI-designer do that.
> 
> And if you're not used to doing it that way, you'll be *stunned* at how
> much stuff tends to factor out and get easily re-used.
> 
> An approach that has more data to work with (some idea of what things are
> doing and what they are for) will beat an approach with less data ("thing
> at row 4, col 2" or, worst case, "thing at 233,144") any day.
> 
> GUI designers are like the regexs in the famous jwz quote: "Some people,
> when confronted with a problem, think 'I know, I'll use a GUI designer'.
> Now they have two problems." Both have a niche in the "quick fix"
> department, both are typically over-used, but overall regexs are the more
> useful of the two; at least there are cases where they are the undisputed
> right answer (like defining tokens in a language parser).
> 
> Generally, over the first couple of weeks of a project, the
> domain-specific language writer may seem to be behind the GUI designer
> cranking out screen after screen of templated GUI widgets, but after a
> couple of weeks the domain-specific language user will pull into the lead
> and never give it up, and will be a lot happier to boot.

First time i hear about domain-specific abstractions.
Do you mean that instead of using a GUI designer, you make some sort of 
engine that constructs a gui for you?

One thing i find repetitive to do is designing gui's that are just 
simple views on a database tables where one can create,edit and delete 
records. If one could construct a gui dynamically for these types of 
things, that would be great.

Benedict