Re: Loadable Nib Views
Re: Loadable Nib Views
- Subject: Re: Loadable Nib Views
- From: Steve Bennett <email@hidden>
- Date: Fri, 09 Nov 2001 12:01:11 -0500
on 11/8/01 5:38 PM, Erik M. Buck at email@hidden wrote:
>
Use a protocol that defines the methods that plugins must support. Do not
>
specify any required outlets (instance variables) for plugins. Instance
>
variables are an implementation detail. If your application must have
>
access to particular objects in the plugin, return pointers to those objects
>
from a method that is in the "plugin protocol".
>
>
> Will this work? Does the Nib file maintain details about the class
>
> interface structure, or does it just maintain a list of outlet and action
>
> names, and compare that against the actual class implementation in the
>
> application which loads it?
>
>
The nib files in the plugin should know as little as possible about the
>
loading application. Similarly, the loading application should know as
>
little as possible about the plugin. Use a protocol and the "file's owner"
>
to communicate between the plugin's nib and the loading application. Better
>
still, require the plugin's bundle to use a class that conforms to a
>
particular protocol as its "principal class". The loading application can
>
deal with the principal class and not know anything about how many nibs the
>
plugin uses.
Um. I probably didn't make it clear, but this isn't a plugin. The bundle
containing these Nibs will have no code at all -- only data. The only thing
resembling code which we'll be supplying to the third party will be the
header file, and that solely so that they can drag it into new Nib files
that they'll be creating, instead of manually having to recreate the classes
and their outlets and actions in each Nib file.
>
If you need help with principal class, file's owner, view hierarchy,
>
bundles, or protocols then
>
RTM.
I have. Many times over now. If the manual were complete, comprehensive,
and intelligible, or I could find the answers on the web, I wouldn't be
asking these questions here. Not that I'm blaming Apple particularly --
it's going to take quite a bit of time (probably years) to take the old
NextStep docs and rewrite them to be as complete and thoroughly
comprehensive as Inside Mac was in the past.