Re: Should I try to avoid loading principal class of plug-in?
Re: Should I try to avoid loading principal class of plug-in?
- Subject: Re: Should I try to avoid loading principal class of plug-in?
- From: Rick Mann <email@hidden>
- Date: Sun, 11 Oct 2009 11:17:17 -0700
Argh, sorry. Stupid Mail reply-to function. Wrong list.
On Oct 11, 2009, at 10:49:32, Rick Mann wrote:
On Oct 11, 2009, at 04:36:42, Gregory Weston wrote:
Rick Mann wrote:
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).
...
Thoughts?
It occurs to me that if you care to distinguish between different
kinds of plugins a user may add to the environment, it's possible
your users may also want to care. Instead of inventing a new key,
why not make them a different document type, with a different
extension and icon?
I've gone back and forth on that idea. At the time I settled on
keeping a single type, I was thinking that a developer might put
multiple plug-ins in one bundle. However, I have not designed the
rest of it to support that. So, that might be a goo way to go.
--
Rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden