From Mahara Wiki

Revision as of 03:44, 31 August 2012 by Mits (talk | contribs) (Hackability (ハックしやすさ))

作成中です - mits





Maharaのコンセプトの核となるものは「プラグイン」です。大部分のMaharaの機能、コア (core) 機能でさえ、プラグインを書くことで実装されています。そして、あなたが変更したいMaharaの部分がプラグインではない場合、Maharaは簡単にハック (hack) できるよう、設計されています。

Hackability (ハックしやすさ)

Maharaは土台から最上部まで、高度に着脱可能な状態に設計されているため、簡単にハック (改造) することができます。この理由から私たちはMaharaのコーディングに関して意図的にPHPを選択しました - PHPに詳しい多くの開発者が存在すること、そしてLAMPの積み重ね (stack) があるからです。MaharaはLinuxの代わりにSolaris/BSD/Mac、Apacheの代わりにNginx/Lighttpd、MySQLの代わりにPostgreSQL (推奨DBMSです) を使用するように、様々なLAMP環境で動作させることができます。Maharaチームがそのような環境でテストすることはありませんが、WindowsおよびIIS環境下で動作させているユーザも存在します。パッチは歓迎します :)

パッチに関して言えば、Maharaはフリーのオープンソースソフトウェアです (恐らく、すでにあなたは知っていると思いますが)。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


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