Re: Renaissance

[Nicola Pero]

<skipping stuff I agree with - thanks for your informed answers!>

> Renaissance is also "tag based" which means that to support a new widget you
> must write a new tag for it.  Gorm supports custom classes automatically, but
> Renaissance needs to have additional code added for new classes (Nicola, 
> please correct me here if I'm mistaken).

Hmmm.  I think the internals are different, but at the end of the day, the
functionality for custom classes is totally similar.  If traditional NIB
archiving/dearchiving can do something better, the same can/should
certainly be done in Renaissance. :-)

=

In traditional NIBs, to support a new class, you need to implement the two
encoding / decoding methods in the class (to encode/decode an object from
the NIB).

In Renaissance, to support a new class, you don't need to implement the
encoding / decoding methods, but you still need to implement code to
read/write the object as a tag; this code is put in a separate class
(rather than in the encoding/decoding methods).  The class does more or
less a similar job of reading and writing the object into/from a tag.  

The reason why you need a separate class has to do with the way the
process has to work to support cross-platform GUIs and custom
autoresizing.  Some more information has to be stored about each object as
its decoded, and that information can't be stored in the object itself
(because we can't add instance variables to, say, NSButton, without making
it a different class).  Storing it in a big lookup table could have been
an option, but keeping an object tree is a much better way of doing it.

=

Maybe you were referring to "simple" subclasses, which do not need special
encoding/decoding code.

If you want to create an instance of a "simple" subclass (one whose
encoding/decoding process is the same as the one in the superclass, or
which differs only for some more outlets to set), you do not need to
implement anything in Renaissace - you can override the default class of
almost anything by using the 'instanceOf' attribute -

<button instanceOf="MyButton" title="Hello" action="Hello:"/>

will create a button and set it up as in a normal button, but create it
from the MyButton class (rather than NSButton).  The encoding / decoding
will work exactly as for a NSButton, just the class used is different (of
course, if your class overrides -initWithFrame: or -setTitle: or
-drawRect:, all your new methods will be used when the NSButton methods
would have been used).

If your subclass has got some additional outlets to set, you can of course 
connect them -

<button instanceOf="SQLButton" title="Update" action="update:" 
        sqlTarget="#NSOwner"/>

in this case, sqlTarget will be set to the FileOwner by using key/value
coding.

All this doesn't require any coding at all, and works consistently and
simply for all tags.

I haven't checked in detail how this works in the new Gorm releases, but I
think it's safe to assume that a similar mechanism is in place - that is,
you can override the class of any GUI object created by Gorm to be a
custom subclass of yours, and that you can connect arbitrary outlets of
objects of these custom subclasses.  Presumably Gorm can parse the
subclass's headers and recognize the outlets in the custom subclass, thus
presenting you with a reasoned choice of stuff you can connect.

A Renaissance-based GUI builder could certainly do similar stuff.  In a
sense, being able to override class names at run time, and connect
arbitrary outlets, are general Objective-C features.

If you see anything good which NIB archiving/dearchiving does and
Renaissance doesn't, please let me know.  It could be a good occasion to
improve Renaissance! :-)