Right now files need for a plugin a spread out in many directories that do not make sense and the process of creating a custom plugin is hard to understand.

We need to think from the plugin author perspective and create a simple, easy to understand structure that can be copied into a module and modified. This encourages learning and extending the system.

Comments

tom friedhof’s picture

tom friedhof commented
Version: » 7.x-1.x-dev
Status: Active » Needs review

The BaseFormatControllers have been moved inside the plugins/tourney_formats directory. The plugins that ship with tourney module use one of these base format controllers as the controller of the plugin.

To create a new plugin, module developers need to create a $plugin definition like the following in their module:

$plugin = array(
  'title' => t('My Cool Format'),
  'machine name' => 'cool_format',
  'description' => t('This is the description of the tournament'),
  'weight' => 5,
  'controller' => 'CoolFormatController', // This controller must implement TourneyControllerInterface
);

Plugins should extend TourneyController to integrate with the Drupal entity system that saves matches and the first game of each match. TourneyController is the gateway between the plugin (the data and logic of tournament) and the Drupal entity system.

Plugin designers don't have to extend TourneyController, they can do what ever they want. When tournaments are saved $plugin->build() (mandatory method from TourneyControllerInterface) is called, as well as $plugin->saveMatches() (not in the TourneyControllerInterface, but if exists in plugin it is called).

Plugins should also be able to render themselves. If the plugin designer is using one of the entities provided by tourney module, the entity will call $plugin->render() on the plugin for rendering.