Plugins

mikldt edited this page Dec 29, 2012 · 14 revisions

To make sure that Concerto is both flexible and uncluttered, some functionality not directly related to the general case of putting content on screens will be relegated to plugins. Concerto Plugins are Rails Engines with a defined set of properties that allow them to integrate with the Concerto application.

In addition to the overview provided below, there are a few more wiki pages documenting Plugins in Concerto

  • [The full listing](Plugins List) of existing and proposed plugins.
  • [Plugin Development](Plugin Development) - a guide to creating a plugin
  • [Plugin Hooks](Plugin Hooks) - documentation for controller and view hooks

Plugin Installation

In general, plugins will be distributed as Gems. The following procedure uses Concerto's built-in plugin installation process to install the gem.

  1. Log in to Concerto as an administrator and navigate to /concerto_plugins.
  2. Click New Concerto Plugin, and enter the plugin details.
  • If installing a released version, simply enter a readable name for the plugin, the plugin's module name, and the name of the gem.
  • If the plugin is not marked as enabled, it will be installed but unusable until it is enabled.
  • If installing a development version, you may change the source to "git" or "Filesystem", and enter the appropriate address.
  1. Restart the web server.
  2. If this fails, try running bundle install from Concerto's install directory, and restarting the webserver when complete.

Plugin Architecture

Concerto Plugins are mountable Rails Engines that have isolated namespaces. Plugins are managed by the ConcertoPlugin model in Concerto.

In order to communicate configuration details back to the main application, plugins customize a PluginInfo object with the following information.

  • Initialization tasks to be run at boot if the plugin is enabled
  • Routing (for controllers contained within the Engine)
  • View and Controller Hooks (For example, linking to hardware management from the screen configuration page)
  • Configuration Objects (that is, settings that can be managed through the dashboard)

In addition, plugins are able to access the classes of the main application to perform other important tasks:

  • Models (For example, querying Screen information)
  • Authentication (Using and adding to the main application's rules)
  • Use Concerto's layout template

The following functionality has also been proposed, but is not implemented yet:

  • Javascript/assets to be included in the frontend
  • Menu Links

The interface between Concerto and the plugins is kept as lean as possible to prevent potential interference between the two. For best results, Concerto Plugins should avoid doing any of the following:

  • Monkey Patching any Concerto Classes
  • Monkey Patching Rails
  • Interacting directly with the Rails object
  • Adding their own initializers outside of the PluginInfo class
  • Providing classes or modules outside of the plugin's root module