開発者エリア/Maharaアーキテクチャインストラクション

作成中です - mits

このドキュメントは、Maharaアーキテクチャの基本イントロダクションおよびアーキテクチャがどのようにコードに反映されているか、あなたに情報提供することを目的としています。このドキュメントを読んだ後、あなたはMaharaがどのように組み合わされているか、新しいプラグインまたはコアコードを書いて、どのように拡張するのか、合理的な理解を得ることができます。

概要

MaharaはPHPで書かれたウェブアプリケーションであり、Moodle、Drupal、phpBBに良く似ています。It uses several libraries to provide framework-like functionality, but is not itself based on a PHP framework such as the Zend framework. In fact, Mahara provides the framework required for you to work within it, such as libraries for database access/form building, and a plugin architecture that allows you to keep your customisations away from hacking the core. In this sense, Mahara is quite similar to other pluggable products like Drupal and Moodle.

Requests that come to Mahara hit specific PHP scripts. There is no dispatcher currently. Requests for the homepage are served by index.php, etc. These scripts load the Mahara core, retrieve the data they need, generate any data structures or forms necessary, then pass that to a templater for display. It's a simple model to understand, where it's easy to tell which PHP script generated which page. It's also portable across many web servers, though it misses the benefits of "clean URLs".

At the core of Mahara is the concept of a plugin. The vast majority of Mahara's functionality - even core functionality - is implemented by writing plugins. And if the part of Mahara you wish to change is not pluggable, Mahara is designed to be easy to hack.

Hackability

Mahara has been designed from the ground up to be highly pluggable, and easy to hack. We deliberately chose to write Mahara in PHP for this reason - as there is a huge collection of developers who are familiar with PHP, and also the LAMP stack. Mahara can run on many variations LAMP, including swapping Linux for Solaris/BSD/Mac, Apache for Nginx/Lighttpd, and MySQL for PostgreSQL (which is the preferred DBMS to use). People have also got Mahara going under Windows and IIS, though the Mahara team doesn't explicitly test under such conditions. Patches are welcome :)

Speaking of patches, Mahara is free, open source software (as you probably already know). There is a small army of developers on the team working on new functionality, bug fixes, helping in the forums and generally improving Mahara every day. Surrounding them is a community of enthusiasts, translators, volunteers, developers and users who improve Mahara in many ways - from developing new features to reporting bugs to suggesting the best way to use Mahara. The point is, it's free software which means you're absolutely encouraged to hack it to death!

Plugin System

A key feature of Mahara's architecture is the plugin system. All sorts of parts of Mahara are pluggable - from the types of content users can have, to how users are authorised, right through to how search is implemented and how groups work. All plugins in Mahara, regardless of their type (more on that in the next section), share some functionality such as the ability to register cron jobs and subscribe to events. There are quite a few subsystems in place to make the job of writing plugins easier as well.

Plugin Types

Where parts of Mahara are pluggable, an API has been created especially for that purpose. For example, the API for user content types contains methods dealing with the content itself and ownership of the content, while the searching API provides methods detailing what search results are required. We call all of these a different type of plugin. Here are some examples:

• The artefact plugin type deals with user content (an item of user content is called an artefact, hence the name).
• The auth plugin type has an API for authorising user accounts.
• The blocktype plugin type provides a pluggable way to put new types of block into the system.

As of Mahara 1.1, the following plugin types are available: artefact, auth, blocktype, grouptype, interaction, notification and search.

This approach has some nice benefits. For example, in parts of the system where one of the plugin types is being used, we don't have to ask every single plugin in the system whether it supports the API - only plugins of the correct type will be used. Plugin types also allows us to customise the API for the actual requirements. For example, a plugin dealing with search can just implement the search API methods, and doesn't have to say that it doesn't support user content, notifications or anything else for that matter.

On disk: Each plugin type has a directory in the htdocs/ folder. Each of these directories contains a lib.php

Plugins

Given the previous section, the plugins themselves are simply instances of a plugin type. So for example, for artefact, the Mahara core ships with plugins for blogs, a file manager, resume and profile information. And in notification, Mahara has 'internal' (which logs messages to a user's activity log), email and emaildigest.

Each plugin has to provide a lib.php, which contains at least one class definition. This class allows the plugin to register cron jobs and events, and also hook into more specific functionality for that plugin type. For example, artefact plugins can register new menu items for the main menu.

In the case of artefact plugins, each plugin can also provide one or more PHP scripts that render pages it requires. In this way, artefact plugins can present highly custom interfaces for managing content, while gaining all the benefits of sharing various properties with other items of content.

On disk: Each plugin is a subdirectory under the appropriate plugin type subdirectory. It provides a lib.php and version.php, and if it needs database tables, a db/ directory. Some plugin types have other directories too - such as theme/ or blocktype/.

In code: Each plugin's lib.php contains a Plugin class which extends Plugin. E.g., PluginArtefactBlog which extends PluginArtefact. This implements the appropriate API. Other classes may be necessary depending on the plugin type.

Next: Core Components

Subpages

• Core Components
• Core Subsystems