RE: Gorm too complex ? [long]

[Bissell, Tim]

RFD wrote:

> Obviously we have a language problem ... but I think from what I'm
> reading that you still don't understand what Gorm does.

I think you are write, he does not understand what Gorm does, or, in fact,
*how* you write code in GNUstep.  This is not a criticism of him, as it
is quite different to how you write code for Java and/or C++ GUIs.  This
may or may not be covered in GNUstep documentation, I haven't checked
because
I already know how to use AppKit!

Bear with me while I try to explain my take on it; I'm sure RFD and others
know
everything I'm going to say.

In one O-O GUI methodology, when you want a window on the screen which
displays
some information in subviews, the natural approach to take is to subclass
the
Window class, and add instance variables to hold references to GUI elements
and other data objects.  You would then add code to the subclass which would
react to changes in the data objects and the GUI elements, and perform any
necessary behaviour.  Thus the Window subclass is also the 'Controller' of
the
GUI behaviour.  A 'GUI-builder' tool for such a system would write the code
for such a subclass; e.g.

class MyWindow extends Window
{
  Slider tempSlider;
  TextField tempTextField;
/// Add your instance variables here

  constructor()
  {
    super(0,0,100, 100); // make window this size
    tempSlider = new Slider(2,2,50,10);  // make slider
    ... etc.
/// Write your initialisation code here
  }

  onMoveSlider(int newValue)
  {
/// Start your code here
    ..... you must write the controller code here
/// End your code here
  }

  ... other methods etc.
}

THE GNUstep methodology is quite different; The Controller object is NOT
a subclassed Window object, it is a completely separate, non-GUI object
which
ONLY provides behaviour. You never need to subclass Window to write the
Controller.  The way it works is that in GORM you create a window in the
interface,
and drag some GUI elements onto it.  GORM actually instantiates the Window
and
GUI elements, sets their frame sizes etc.  It also creates a 'pseudo-object'
called
the File Owner, which is representation of the Controller class you need to
write.
Inside GORM you can define instance variables and method names for the
Controller,
and attach your Window and other GUI elements to the Controller using them.
You can then either write the controller by hand, or get GORM to generate a
skeleton
of it for you; in the same pseudocode:

class MyController extends Object
{
  Window window;
  Slider tempSlider;
  TextField tempTextField;

  constructor()
  {
        // you must write code which loads the .gorm file
      // this looks like (can't remember exactly, havent coded Appkit for
ages)

      // Bundle.loadGormFile(name:"MyWindow" fileOwner:self);

        // and the Bundle code 'takes care' of the GUI initialisation, it
recreates
      // the Window and other GUI elements, then sets up the connections;
e.g.
      // MyController.window <- <the window object ->.
  }

  onMoveSlider(int newValue)
  {
    ..... you must write the controller code here
  }

  ... other methods etc.    

And then you write the behaviour of the controller object.
As well as creating the GUI objects in GORM, you connect them together in
it.  You
would connect the File Owner 'window' ivar to the Window object, and the
'tempSlider'
ivar to the Slider GUI object.
The Slider object is designed to send a message to a controller object when
it has
had its slider position moved. In GORM you connect the Slider to its
Controller (in
this case the File Owner) and tell it which method in the File Owner to
call.

GORM writes out the .gorm file loaded by Bundle above.  The gorm file
contains the
'Frozen' Window and Slider and TextField objects, and details of their
connections
to the contoller objects e.g.

<Window: instance {Serialised state here}, ID=1>
<Slider: instance {Serialised state here}, ID=2>
...
<GORM-FileOwner: isa MyController, ID=99>

<attachVariable: #99.window #1>
<attachVariable: #99.tempSlider #2>
..
<attachVariable #2 #99.onMoveSlider>
...


So you can see from the above you do not need to subclass Window to act as a
Controller,
and you do not need to write code to connect GUI elements together; simply
write the Controller code, and use GORM to connect objects together.  The
'Code writing' parts
of other GUI builders exist only because their programming models have not
cleanly separated the controller code (which you write) from the GUI, which
is accessed by
the controller.

Note that I have not described GORM exactly, I have changed names and left
out stuff
etc. to simplify it in the description.

Note^2 I have not used GORM yet, just its spiritual predecessor!

I hope this post helps people who don't yet 'grok' GORM (but know other GUI
builders)
move further along the path to enlightenment!

regards,

Tim


----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail 
disclaimer statement and monitoring policy, please refer to 
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------