Re: Loadable Nib Views
Re: Loadable Nib Views
- Subject: Re: Loadable Nib Views
- From: "Erik M. Buck" <email@hidden>
- Date: Thu, 8 Nov 2001 16:38:55 -0600
>
1) The views are custom views, and can contain custom subviews. The
problem
>
is, the actual interfaces (data and available methods) may have to change
>
without our being able to change the Nib files making use of them.
>
>
What we'd like to do is provide a header file which defines *only* the
>
IBOutlet and IBAction entries of each needed class. This header will be
>
used by the people making the Nib to make the necessary connections, but a
>
different header with the full class interface definition will be used in
>
the application.
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.
Here is a rough sketch in code:
@protocol MYPluginProtocol <NSObject>
- (NSView *)handyView;
@end
In the loading application
- (void)loadPluginAtPath:(NSString *)aPath
{
NSBundle *pluginBundle;
Class pluginClass;
// load the bundle containing the plugin
pluginBundle = [NSBundle bundleWithPath:aPath];
// Get the principal class
pluginClass = [pluginBundle principalClass];
if([pluginClass instancesConformToProtocol:@protocol(MYPluginProtocol)])
{
// The princiapl class conforms to the required protocol
id <MYPluginProtocol> pluginInstance;
NSView *interesingView;
// Allocate and init an instance of principal class
pluginInstance = [[pluginClass alloc] init];
// get the handy view from the plugin instance. The plugin instance
// might actually load a nib from its bundle in response to the
handyView
// message. The pluginInstance migt be the file's owner for the loaded
nib
// and have access to the views in the nib via outlets
interesingView = [pluginInstance handyView];
// Standard idiom for removing a view from one superview and adding it
to another
[interesingView retain];
[interesingView removeFromSuperview];
[_myViewThatContainsPluginViews addSubview:interesingView];
[interesingView release];
}
else
{
// Error: invalid plugin
}
}
If you need help with principal class, file's owner, view hierarchy,
bundles, or protocols then
RTM.
>
>
2) If my application knows the Nib filename containing a view and the name
>
of a view within that file, how does it get the pointer to the actual view
>
object? The documentation on NSBundle Additions tells me how to load the
>
Nib, but nothing understandable on how to enumerate or access the objects
>
within it, and I've done a Google search but came up with nothing better.
>
>
>
-->Steve Bennett
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev