Introduction

OntoWiki has been extensible since version 0.8. In OntoWiki 1.x this goes even further and the extension architecture has been simplified.

• Introduction
• Extension Architecture
• Components
• Modules
• Plugins
• Events
• FAQ

Extension Architecture

OntoWiki differentiates between three kinds of extensions:

• Componentes,
• Modules and
• Plug-ins.

Additionally, we have 2 kinds of non-developer extensions, namely

• translations and
• themes.

Components

Components are pluggable MVC controllers to which requests are dispatched. Usually but not necessarily, components provide the main window's content and, in that case, can register with the navigation to be accessible by the user. In other cases components can function as controllers that serve asynchronous requests. Components are statically configured by a component.ini file within the component's folder.

Components can be associated with a helper object that is instantiated on each request (instead of just requests the component serves). Thus you can use a helper to do certain tasks like registering a menu or navigation component. Se also the component helper section of the RDFa Views page.

In both cases, the component controller mus extend OntoWiki_Controller_Component and has therefore a number of inherited variables and methods available. If your component needs a helper, derive you helper class from OntoWiki_Component_Helper`.

Typical things you can do with a component:

• a new tab in the main window (e.g. with your special data view)
• a new webservice service endpoint (e.g. to export data in your special way)

Components, where you can sneak good code:

• files component

Modules

Modules display little windows that provide additional user interface elements with which the user can affect the main window's content. Since some modules are highly dynamic extensions, they can be configured both statically and dynamically. Static configuration works in the same way as with other extensions; a module.ini file is placed in the module's root directory. In addition, a module class needs to extend OntoWiki_Module and can redefine several of its methods in order to allow for dynamic customization. If present, return values will overwrite static configuration settings in the module.ini file.

Module classes must be named with an extension Module appended to the module name with the first letter capitalized.

Typical things you can do with a module:

• an additional top-left window with your specific navigation
• an additional inner-window for your specific resource type

Modules, where you can sneak good code:

• application module

Plugins

Plug-ins are the most basic, yet most flexible types of extensions. They consist of arbitrary code that is executed on certain events. Plug-ins need to be registered for events in the plugin.ini config file that has to be placed in the same folder as the plug-in class. There is no specific base-class required for a plug-in. The only requirement is that the class name must end with the suffix Plugin, which is appended to the plug-in's name (e.g. the folder) with teh first letter in upper case.

Typical things you can do with a plugin:

• an action which is executed every time a statement is added (e.g. for your specific rules)
• just everything which is "accessible" via an event :-)

Plugins, where you can sneak good code:

• linkeddata plugin

Events

old page: http://ontowiki.net/Projects/OntoWiki/EventPluginArchitecture

FAQ

• Q: How do I create a new tab? A: A tab in OntoWiki needs to be registered with OntoWiki_Navigation.

OntoWiki_Navigation::register(
    $tabKey, 
    array(
        'controller' => $controllerName, 
        'action'     => $actionName, 
        'name'       => $displayedName, 
        'position'   => $position, 
        'active'     => $activeTab
    )
);

• Q: How can I replace OntoWiki strings? A: Provide your own language CSV file that replaces OntoWiki language keys.

• Q: How do I get the Theme Base Dir? A: In a phtml-file, you can use $this->themeUrlBase