CruiseControl.NET : Developing Web Dashboard Plugins
This page last changed on Aug 09, 2005 by mroberts.
The Web Dashboard supports custom plugins. This page is documentation for developing your own Dashboard plugins.
First of all, you need to decide what type of plugin you are developing:
The CruiseControl.NET Web Dashboard includes its own Web Framework implementation. The fundamental 'component' in this framework is an Action. An Action represents a specific interraction between the application and a user. Some features require multiple actions, e.g. one Action to allow a user to edit some fields, and then another to show the results of this.
Your Dashboard Plugin must include at least 1 Action. It can include more than 1, but only 1 will ever be linked directly from the Dashboard menus (the others must be linked by your other actions.)
The Actions you write should implement ICruiseAction. This has one method on it:
The responsibilty of an Action's Execute method is 'Given a request, generate a response'. The response is the 'main panel' part of the Dashboard's UI.
The CruiseControl.NET Web Dashboard uses a Constructor Dependency Injection (CDI) pattern to enable classes to define what types they are dependent on. The Dashboard API has a number of types you can depend upon which can do things like return you the currently viewed build log. You can also specify dependencies to your own types. It is recommended that you use interfaces to define responsibilities.
The Dashboard's CDI implementation does not currently allow for runtime configuration. It will use sensible defaults where available. We plan on adding more configuration later.
To implement your own actions, its probably best to first look at the source code for the Dashboard's own plugins. These are available in the ThoughtWorks.CruiseControl.WebDashboard.Plugins Namespace.
Once you've written your action(s), your Plugin is almost complete, but you have one more interface, IPlugin, to implement. For simple , single-action, plugins you can just implement this interface on the same class as your action, otherwise it must be implemented on another (single) class.
IPlugin contains the following properties:
The Actions property returns instances of all the Actions in your plugin. An Action is specified (in a INamedAction) by giving the action instance itself, and also a (unique) Action Name that will be used by the Web Framework's controller to route user requests. Action Names should just include alpha-numberic characters (i.e. only a-z, A-Z, and 0-9).
The Actions property must return an array with at least one INamedAction.
The first named action, i.e. Actions0 will be the Action linked to through the Dashboard UI.
For all of this look at existing implementations to see how CruiseControl.NET defines its own plugins.
Build Plugins have a slight complication, in that they must implement the slightly richer interface IBuildPlugin rather than IPlugin. Most Build Plugins will do this by extending the ProjectConfigurableBuildPlugin class, which automatically makes them a Project Configurable Build Plugin - simple!
Apart from that Build Plugins are identical to other plugins.
To deploy your plugin:
|Document generated by Confluence on Jan 23, 2011 08:52|