Overview

This documentation provides sample implementations of the plugin architecture for Ed-Fi Dashboards. The intent is to provide detailed information about the creation of plugins and the complete interaction with data, services, and views while documenting the overall plugin architecture and major conventions so that an accomplished developer in the technology can successfully create plugins.

Audience

The primary audience for this document are developers implementing plugins for dashboards powered by Ed-Fi.

Prerequisites

The Ed-Fi platform architecture uses a collection of design patterns, architectural best-practices, conventions, and databases. In order to understand the code base and be able to write a plugin, it is important to understand these patterns and techniques. It is recommended that a developer intending to implement a plugin has knowledge and understanding of the dashboard’s extension mechanisms and has completed the dashboard setup guide. Setup information is available in the Ed-Fi Dashboards Getting Started guide and detail about the dashboard architecture can be found in the Ed-Fi Dashboard Developers' Guide.

Basic Guidelines for Implementing a Plugin

There are a few basic guidelines that are very important and should be followed
when developing a plugin:

1. All plugins should be mutually exclusive and self-contained. Plugins are intended to be new functionality that gets added to the dashboards.
2. Plugins follow the basic Ed-Fi conventions for extensions. See "Extension Framework Guide" 
3. Plugins should use the convention-based project names starting always with EdFi.Dashboards.Plugins.[PluginName].[ProjectType]. For example: EdFi.Dashboards.Plugins.[PluginName].Resources,

   EdFi.Dashboards.Plugins.[PluginName].Data.

4. A new plugin should always be developed under the current EdFi.Dashboards.Plugins.Web version. This means that if this project is MVC 3 with .Net Framework 4.0, you should use MVC 3 with .Net Framework 4.0 or the plugin will not work.
5. JavaScript and CSS files need to be declared as Embedded Resources.

Technical Overview

The plugin architecture hooks into the existing dashboard by leveraging the CastleWindsor Inversion of Control (IoC) container. When the container is created, on Application_Start, it looks in the ~/Plugins
directory for appropriately named DLLs. If it finds any plugins, it then uses reflection to create instances of classes that implement the IWindsorInstaller interface. The IWindsorInstaller classes are responsible for wiring up the dependency injection for the plugin.

Once the IoC container has been initialized, the dashboard initializes the MVC framework. During this initialization, the dashboard will again look in the ~/Plugins directory for appropriately named DLLs. If it finds any plugins, it then registers all of the custom routes, controllers, and views. If the plugin has embedded JavaScript or CSS files, it creates the Cassette bundles for those embedded resources.

At this point, the plugin is available to be consumed.