Should I try to avoid loading principal class of plug-in?
Should I try to avoid loading principal class of plug-in?
- Subject: Should I try to avoid loading principal class of plug-in?
- From: Rick Mann <email@hidden>
- Date: Sat, 10 Oct 2009 21:53:43 -0700
I'm working on a plug-in-based app. While I have to scan all of the
plug-ins and load some information from their info.plists, I don't
necessarily need to load any of the code until a plug-in is actually
used. My main question is, is it worth it to do this? It seems like
that's one advantage of plug-ins, but now I'm at a point where it's
more elegant if I can determine if the plug-in class derives from a
particular base class, rather than storing a key in info.plist (it
would be redundant).
1) I'm assuming [NSBundle bundleWithPath:] doesn't load a bundle's
code, right? The docs seem to suggest this is the case.
2) Once the principal class is loaded, everything is loaded, right?
Plug-ins get grouped into a few different types, and it seems nicer to
distinguish any given plug-in by what base class it inherits, rather
than by specifying a key in the bundle's info.plist. The latter
approach means a plug-in developer has to ensure that the proper key
is present, the former requires loading of the code on app startup
(when it scans plug-in directories to build a list of available plug-
ins).
I suppose I could look for the key, and if it's not present, then load
the principal class and find out.
Thoughts?
TIA,
Rick
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden