Re: Gorm too complex ?

[Richard Frith-Macdonald]

On Monday, February 11, 2002, at 09:21 AM, Peron, Stéphane wrote:

>         The .gorm generated is good because, it is :
>                 1) the primary file to save the work done in Gorm
>                 2) the file used to launch application done by Gorm. As I
> have read, It is portable. Well many advantages....
>
>         The only think that I try so say as gnustep beginner, is that
> sometimes, the latter should'nt use by all of us. Because Gorm doesn't
> provide all we need, indeed (75% ..... so time to time, I need the 
> missing
> 25% ).
>         So, naturally the .gorm must be kept.
>         But sometimes I need to go into the code by hand.
>         (I hope my bad english is comprensive enough ;-( )
>         I this case, Gorm could provide primary classes which definition is
> saved in a .gorm file.
>         And we could instantiate them by hand to improve what missing.
>
>         So, I this case, when primary classes will be regenerated (thanks to
> the .gorm file), it will not overwrite code in instance classes.
>
>         Well ... do am I comprehensive enough ?

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

You say '2) the file used to launch application done by Gorm.'

but Gorm does not have anything to do with launching the application.

You say 'Gorm could provide primary classes which definition is saved in
a .gorm file. And we could instantiate them by hand to improve what 
missing.'

but Gorm does not provide classes (except where you ask it to generate 
.[hm]
files for custom subclasses, and I don;t think that's what you are 
meaning).

What Gorm does is provide archives of *objects*  and their 
relationships -
no coding involved.
Having Gorm export source code would in no way help provide the remaining
25% of functionality that Adam quoted ... the source code it exported to
create objects at runtime would duplicate the 75% that Gorm already does
for you.   Adding that extra information would require you to write extra
code anyway.

Gorm *does* provide the ability to subclass existing classes, add outlets
and actions to those classes, and export template .[hm] files for the
classes - so it already gives you the framework to add your own source
code.  I don't think that's what you are talking about though.

Gorm *cannot* give you the source code of existing classes ... it doesn't
have them ... they are in the gui library.  The most it could give you
in place of archived objects is a chunk of code to set up instances -
Yes, you could then add to that code to send messages to the objects to
change them, but equally you could load the .gorm file then send messages
to the resulting object ... no difference ... nothing gained by using 
source
rather than archived objects.
More importantly, such code can go in your main application source ...

Eg. a window created programmatically using

window = [[NSWindow alloc] init];
// where 'window' is an ivar of the object creating the new window.

would be no different to one obtained by using

[NSBundle loadNibNamed: @"MyNib.gorm" owner: self];
// The .gorm file sets the 'window' ivar of self to point to the new 
window

In either case you could go on to do

[window setFrame: newFrame];
[window orderFront: self];

So that the size/position of the new window when you display it is set 
at runtime.