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

作成中です - mits (talk)

このドキュメントはあなたにMaharaアーキテクチャの基本的な情報およびコードとの繋がりを提供することを目的としています。このドキュメントを読むことにより、あなたはMaharaの連携、プラグインの開発による拡張、コアコードのハッキングに関して理解することができます。

概要

MaharaはPHPで書かれたウェブアプリケーションであり、Moodle、Drupal、phpBB等に良く似ています。フレームワークのような機能を提供するため、Maharaはいくつかのライブラリを提供しますが、これ自体はZendフレームワークのようなPHPのフレームワークをベースにしていません。実際のところ、Maharaはデータベースアクセスおよびフォーム構築のようなフレームワークを提供しています。そして、あなたはその中で作業を進める必要があります。また、プラグインアーキテクチャによりあなたのカスタマイズはコアコードの改変を避けることができます。この点において、MaharaはDrupalおよびMoodleのようなプラグイン設置可能なソフトウェアに非常に類似しています。

Maharaへのリクエストは特定のPHPスクリプトにヒットします。現在、ディスパッチャはありません。ホームページへのリクエストはindex.php等により扱われます。これらのスクリプトはMaharaコアを読み込んで、必要なデータを検索して、必要なデータ構造またはフォームを生成して、それらを表示するためテンプレータに渡していました。これはどのPHPスクリプトがどのページを生成するか簡単に把握することのできるシンプルなモデルです。「クリーンURL」の利点を失うことになりますが、多くのウェブサイトにとって移植可能な方法でもあります。

Maharaコアのコンセプトはプラグインです。大部分のMaharaの機能はコア機能であってもプラグインを書いた上で実装されています。そして、あなたが変更したいMaharaの部分がプラグインに対応されていない場合、Maharaは簡単に改変できるよう設計されています。

ハッカビリティ

Maharaは基本部分からすべてにおいて高度に着脱および簡単に改造できるよう設計されています。PHPおよびLAMPスタックに慣れている多くの開発者が存在しているため、私たちはMaharaを意図的にPHPで書くようにしました。MaharaはLinuxからSolaris/BSD/Macへの移行、ApacheからNginx/Lighttpdへの移行、およびMySQLからPostgreSQL (推奨DBMS) への移行も含めて、多くの様々なLAPMで動作させることができます。Maharaチームが厳密にテストしたわけではありませんが、MaharaをWindowsおよびIISで動作させた人もいます。パッチは歓迎します :)

パッチに関して話しますと、あなたがすでに知っているようにMaharaは無料のオープンソースです。Maharaの小規模の開発部隊は新しい機能、バグ修正、フォーラムでのサポート、Maharaの一般的な改善に日々関わっています。新しい機能の開発からMaharaの最良な利用の提案に関するバグレポートの投稿等、開発部隊のまわりには熱心なコミュニティ、翻訳者、ボランティア、開発者および多くの部分でMaharaの改善に尽力するユーザがいます。重要な点はMaharaがフリーソフトウェアであり、あなたが思う存分ハックできることです!

プラグインシステム Plugin System

Maharaアーキテクチャの重要な特徴はプラグインシステムであることです。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.

次へ: コアコンポーネント

サブページ

• Core Components
• コアコンポーネント
• Core Subsystems
• コアサブシステム