Plugin API Wishlist
Methods to indicate start/end of preview/export/publish generation
Right now, there's an implicit assumption in the API about the order in which the various export methods get called (i.e. -contentHTML:, -extraFilesNeededInExportFolder:, etc).
Plugins that create a lot of context for an export have to make some pretty icky assumptions about what's going to get called when during an export in order to manage the context (and release it after the export is complete). This means that -contentHTML: usually has a lot more in it than it should do.
It'd be good to have some "framing" method calls to indicate the start and end of export processing for a plugin.
- (void)exportStart:(NSDictionary*)parameters; - (void)exportComplete:(NSDictionary*)parameters;
These'd be optional for a plugin to implement.
Building on the above wish... it would be great to have global bracketing NSNotifications for export. This would help a lot to write non-page plugins that might be interested to know that export/publish is going on. The notifications could contain params such as: mode, document, etc. The ending notification could append an extra param for final status (successful export, failure, cancelled).
Site Defaults For Plugins
RapidWeaver is very page-oriented, which is a good thing. However, it means that if you have a lot of pages for a specific plugin, it's fairly awkward to share settings between all the pages without having to brew up a weird pseudo-singleton class (i.e. it's not a singleton because you need one per open document).
It'd be really useful to be able to access an NSMutableDictionary in the RW3 NSDocument accessed by a plugin class/name. That way, we could add a dictionary of parameters on a per-site basis for a plugin. Sure, it's possible to work around this but it means that every plugin developer has to home-brew their own solution. This is one of those things that'd be a lot easier if the plugin API provided it.
Note that RapidWeaver would be responsible for encoding/decoding the plugin site dictionary and that this should be done before the plugins are initialized (so that they can access the values when they start).
Bundle support for Plugins
Adding well-defined support for plugin "template" bundles would be great. The idea here would be that we'd declare a new extension for RapidWeaver for bundles that contain templates and/or canned configurations for plugins. This is similar to the way RapidWeaver currently defines theme bundles. For want of a better term, lets call it ".rwbundle" for the moment.
If a user double-clicked on an ".rwbundle" file, RapidWeaver would open it and copy it to a well-defined location in the User Library. It probably makes sense to use subfolders based on plugin names (so that it's easy for plugins to find bundles that apply only to them). Once copied, the bundle would be keyed on the CFBundleIdentifier in the Info.plist file and the bundle details handed off to a class method for a plugin.
Why do this? Well, it makes distributing plugin configurations just like distributing themes and the plugins themselves and makes for a far smoother user "experience" (wearing my seldom-used marketing hat ;-).
