From: Stephen Tashiro <tashiro@...>
Date: 2006-04-07T21:06:12+09:00
Subject: Separation of gui from "real work"

This is not a ruby specific topic but since there were some definite 
opinions expressed about systems of writing GUIs in a recent thread, let 
me ask it here.

Is there a practical program architecture for separating the gui portion 
of a program from the part that does the "real work"?  Or is this just a 
high flown idea that is rarely practical?

Conceptually,  one could write "the real work" part of the program as a 
kind of state engine that is driven by an "interface" which provides 
inputs and receives outputs.  Various "interfaces" could be written. 
For example, one might use console I/O, another might use WxWidgets, 
etc.  Perhaps if the "real work" part of the program is not that hard, 
this is overkill.  But, for example, when I want to try to write some 
fairly hard numerical problem (and when I am unsure of whether my ideas 
about it are sound!) the last thing I want to do is start thinking about 
how to design a gui interface for it.  It goes faster to read the inputs 
from a file and print the outputs on the console.  But, on the other 
hand, I don't look forward to separating the "real work" from a 
gui-to-be-written-in-the -future-in-some-as-yet-to-be-determined-system 
by writing the file-and-console interface.  Perhaps this seems tedious 
because I haven't had enough practice writing interfaces of either kind.

There are approaches that pride themselves in binding the gui tightly 
together with the application without any intermediate interface.  For 
example, Fox lets you bind a "real work" variable to something 
represented in a gui.  I think in this point of view, you treat the 
"real work" as a collection of services (not as any kind of state 
engine).  Then you use the gui as the glue that puts them together into 
a useful machine.







-- 
Posted via http://www.ruby-forum.com/.