Re: protocol/plug-in question
Re: protocol/plug-in question
- Subject: Re: protocol/plug-in question
- From: Ryan Britton <email@hidden>
- Date: Wed, 5 Apr 2006 19:42:02 -0700
I have generally done this by letting the plugin handle all of its
own configuration; the application itself is just a mediator for
persistence. One way this can be done is to have each plugin provide
a specific object type for its settings (say an NSDictionary) and
handle storing/retrieving these from this object themselves.
For example, a typical process may go like this:
- Application Launches
------- Plugins are loaded
------------- Application loads settings dictionaries from some store
and initializes each plugin
------- Application ready
------- User changes settings via plugin-provided interface
------------- Plugin requests save operation with setting dictionary
from application
------- Application ready again
In pretty much every case I've seen and done, plugins all conform to
a specific interface provided by the application. The application
will call these methods on a plugin, at most checking to see if it
responds to it but never changing the actual method called. The
plugin receives the message and does whatever it needs to do then
with what it was provided, possibly providing its own UI widgets
(such as NSCell subclasses or NSView subclasses) to handle display.
It is expected to adapt to the constraints of the application and not
the other way around.
Suppose there's a hypothetical application that takes pasteboard data
and displays it in a meaningful way. Given the way NSPasteboard is
designed, there is no possible way for the application to ever handle
every case so it provides a plugin interface for developers to use as
they introduce new pasteboard types. Since the application is
oblivious to what is actually contained in a pasteboard entry, it can
only ask the plugins, "do you know how to display this?" If one
responds, it gets custody of that pasteboard entry and passes back an
NSCell subclass initialized to that data and will draw it wherever it
is told to.
In your case, it sounds like your shapes need to provide their own
editing interface. You might approach this by having the plugin
provide a view you just add as a subview or you might provide a form
builder that can parse a requirements list and generate a set of
fields (though of a fixed number of types most likely) and display
that. Tables require that all of the data contained conform to a
specific set of fields, so you'll be restricted to whatever is common
among all of your shapes (name, picture representation, color, etc)
for the display of the table. You can, however, provide an inspector
for each row that is provided by the plugin in some way to handle
specific configuration much like those in Photoshop for the tools
palette or Interface Builder for the widget attributes.
All that said, the general rule for a plugin API is that you can
never remove anything. If you deprecate something in favor of
another option, the old option still needs to work.
On Apr 5, 2006, at 5:53 PM, Ondra Cada wrote:
Ryan,
On 6.4.2006, at 2:43, Ryan Glover wrote:
I am attempting to create an app that I want to be expandable via
plug-ins. I have read up on protocols and they seem the right
solution.
Perhaps they do, but pretty often they don't. Consider also
informal protocols etc.
Formal protocols are hell upgrading: you cannot extend the current
one lest the old conformats get out of sync.
... But each plug-in might have different inputs.
For example, a cube only needs to know the length of one side
while a
cylinder needs to know height and a radius. If the array is
presented
in a table and I click on a particular row in the table (which
represents an instance of a shape) how does the code know what
parameters are applicable? Do individual instances present a list of
their methods that can be interrogated at run time?
Depends, and completely up to you. Each plugin object may present
its own UI view. Or all may be set up with a string, whose contents
each will parse its own way. Or you can invent your own protocol in
which the plug-in would return a formal list of arguments it wants
(their types, descriptions, etc.)
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden