RE: Gorm too complex ? [long]

[Peron, Stéphane]

Ok ...thanks Tim for your explanations ....

Imagine that I have created a graphic object that is naturally not providen
by Gorm .....
Can I use Gorm in this case ?

Thanks
 

> 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.
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep


Ce message contient des informations confidentielles ou appartenant au
Crédit Lyonnais et est établi à l'intention exclusive de ses
destinataires. Toute divulgation, utilisation, diffusion ou reproduction
(totale ou partielle) de ce message, ou des informations qu'il contient,
doit être préalablement autorisée. Tout message électronique est
susceptible d'altération et son intégrité ne peut être assurée.
Le Crédit Lyonnais décline toute responsabilité au titre de ce
message s'il a été modifié ou falsifié. Si vous n'êtes pas
destinataire de ce message, merci de le détruire immédiatement et
d'avertir l'expéditeur de l'erreur de distribution et de la destruction
du message.

This e-mail contains confidential information or information belonging
to Crédit Lyonnais and is intended solely for the addressees.
The unauthorised disclosure, use, dissemination or copying (either whole
or partial) of this e-mail, or any information it contains, is prohibited.
E-mails are susceptible to alteration and their integrity cannot be guaranteed.
Crédit Lyonnais shall not be liable for this e-mail if modified or falsified.
If you are not the intended recipient of this e-mail, please delete it
immediately from your system and notify the sender of the wrong delivery
and the mail deletion.