Discussion: Advanced extension points for new/open/save

In a branch I've started cleaning up the UI so that "new", "open" and "save" are all "top level" menu items which show their own submenus. This allows us to declutter the UI so that "save/save all", "open/open from web", "new/new jekyll page" aren't taking over the entire screen.

We could extend this further, so that publish or save could be extension points so that we could get docx/html export (#135, #136) in the app without being in core code. This could also be used for opening or importing from different sources, having new file templates (even creating your own), etc.

I thought I'd open a discussion on how we could be tackle this before diving straight in.

[becdetat]

I won't pretend to be a architect guru but a sort of plugin-ish system would be nice. Given some interfaces:

interface ICreateFiles { Document CreateFile(); string CreateFileLabel{get;} }
interface ISaveFiles { void SaveFile(Document); ... }
interface IOpenFiles { void OpenFile(); ... } // leave prompting for path up to the implementation

, scan for implementations of the interface, list them in the settings dialog to enable/disable, and show the label in the appropriate ui. (There's probably a better way of implementing this with event pub/sub or something that I haven't got my head around yet).

Hooks into configuration could be done by implementing an IProvidePluginConfiguration interface that passes back a ViewModel that can be shown as a dialog. Then implementations can be moved out into their own assemblies, at least for core plugins like Jekyll.

I don't know how the existing Jekyll system works though so this may not work without modification or leaving Jekyll integration in as a special case. Regardless, an option to hide Jekyll integration would be nice.

I personally would love (and may be able to contribute) a PDF export but that would probably need multiple third-party assemblies which will get messy. So we could have a plugins folder with a subfolder per third-party plugin, which are loaded (via naming convention? plugins\*\*MarkPadPlugin.dll?) and scanned for implementations.

MEF gives assembly/extension loading, and conventions are nice... but we could take it one step further and setup our own Nuget Gallery for MarkPad extensions (could be used for all Code52 extensions), that way we get browsing/centralisation in one!

As for the existing Jekyll system, we'd pull that out, make it use whatever interfaces we end up with, but still have it baked it.

[becdetat]

Can Nuget be integrated in the app itself? It would be cool to have an in-app plugin galleries a la VS.

Yup, thats exactly the thinking. Comicster has this system, although I'm thinking of running a full nuget gallery install http://matthamilton.net/nuget-for-plug-ins

I've got a (work in progress, don't actually use..) gallery up at http://code52extensions.apphb.com/, customised theme, using Rackspace for storage.

[becdetat]

FYI this is in development here: https://github.com/belfryimages/DownmarkerWPF/tree/plugin_support

This is based on an experimental spike that I've discarded: https://github.com/belfryimages/DownmarkerWPF/tree/experimental_extensions_support

I dropped NuGet support because it added too much complexity early on, so the initial plugins will be built-in. Once the plugin system is solid it shouldn't take too much to add NuGet in.

I should have a PR ready in a couple of days. Suggestions are welcome. My personal Trello board for MarkPad work (showing remaining tasks for the branch) is here