How to allow plug-ins to expose plugin-specific menus, add form entries to application settings...?

Question

Hi,

while developing application that supports plug-ins, I am wondering what is the best approach to allow plug-ins to create its own menu entries in interface, add menu options to existing menus, add certain options to configuration dialog of application, that kind of stuff, and, how to handle saving those changes? If plug-in has knowledge of options it has added to form, how should it handle saving those modified options?

I believe it would be better approach to expose generic methods like GetMenuOptions() or GetConfigurationOptions(), something along the lines, so that host application actually manipulates those things, instead of passing menustrip object or config form object to plugin for it to modify? Am I on the right track, design-wise? Is there some common pattern for that?

Platform/language: .net/c#

Thanks!

Answer 1

A common approach is to use a combination of Verbs and Services. As part of your plugin architecture, you could provide an interface, something like IInterfaceService whereby you can consume multiple instances and use them to extend your interface, e.g.

public interface IInterfaceService
{
    IVerb[] GetVerbs(string category);
}


public interface IVerb
{
    string Category { get; }
    string Name { get; }


    void Action();
}

This is obviously quite simplistic, you'd need to flesh out whatever you need. If you based the majority of your extension points around something similar, yo could make it quite easy to allow the insertion of command verbs etc.

Hope that gets you started.

Answer 2

Option 1: Central menu entry repository

• Plug-ins register their links into a central system, which all menus use.
• Repository could be low-tech config file or high-tech database which users can configure in admin section.

Pros

• all menu data held in one central place that's easily manageble
• menu options can be cached and used without firing up the plug-in (faster)
• eaiser to wrap security around it (as it's effectively static data).

Option 2: Define by Attribute

• Define one or more attributes in a lean common assembly (by lean I mean few / no dependencies); plug-ins define menu options via these attributes.
• Use reflection to get the options out - either at runtime, everytime, or cache on app start-up.
• You could probably also (via the attributes you define) define user-role profiles that the plug-ins could tap into to control access to the menu options - such as admin / normal / aithenticated / un-authenticated users.

Option 3: Plug-ins adhere to interface, supply menu data on demand

• The central repository of menu items is virtual, and exists at runtime only: when a menu is called it has to be built up by logic. This is flexible but complex, and probably not very efficient.
• The logic call to talk to every plug-in, regardless of whether that plug-in has any menu options for the menu being built. Yes you could do this once and cache it - but you'd be better off just diong option 1.