Actions

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

From Mahara Wiki

Revision as of 04:27, 21 September 2012 by Mits (talk | contribs) (プラグインタイプ)

作成中です - mits

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

概要

MaharaはPHPで書かれたウェブアプリケーションであり、Moodle、Drupal、phpBBに良く似ています。フレームワークのような機能を提供するため、いくつかのライブラリを使用しますが、それ自体はZendフレームワークのようなPHPフレームワークをベースとしているわけではありません。実際、あなたが作業するのに必要なデータベースライブラリおよびフォーム作成のフレームワーク、そしてあなたのカスタマイズに関してコアをハックしなくても済むようなプラグインアーキテクチャをMaharaが提供します。この意味で、MaharaはDrupalおよびMoodleのようなプラグイン着脱可能なソフトウェアと良く似ています。

Maharaへのリクエストは直接PHPスクリプトに向かいます。現在のところ、ディスパッチはありません。ホームページへのリクエストは、index.php等によって処理されます。これらのスクリプトはMaharaコアを読み込み、必要なデータを検索して、データ構造または必要なフォームを生成した後、これらを表示のために渡します。どのPHPスクリプトがどのページを生成するのか簡単に分かることができるため、理解するのにシンプルなモデルです。「クリーンURL」の利点を逃すことになりますが、多くのウェブサーバに移植することができます。

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はフリーのオープンソースソフトウェアです (恐らく、すでにあなたは知っていると思いますが)。チーム内には、新しい機能、バグフィックス、フォーラム投稿サポート、Maharaの一般的な改善等に毎日関わっている小さな開発部隊が存在します。開発部隊を取り囲んでいるのは、熱心なコミュニティ、翻訳者、ボランティア、開発者および様々な方法でMaharaを改善するユーザです - 新しい機能の開発からバグ報告まで、Maharaの使用に関して最善の方法を提案しています。重要な点は、Maharaがフリーソフトウェアであり、あなたは無条件に思いっきりハックできるということです!

プラグインシステム

Maharaアーキテクチャの重要な特徴はプラグインシステムです。Maharaのパーツすべてはプラグイン着脱可能です - ユーザが持つことのできるコンテンツから、ユーザの認証方法、検索の実装およびグループのワークまでがプラグイン着脱可能です。タイプ (次のセクションで詳細説明します) に関わらず、Mahara内のプラグインすべてはcronジョブの登録およびイベントの購読等、いくつかの機能を共有しています。極めて少ない数のサブシステムが実装されていることも、プラグインの作成を容易にしています。

プラグインタイプ

Maharaの部品がプラグイン着脱可能であるため、特にAPIはその目的に合致するため作成されました。例えば、検索APIではどのような検索結果が必要であるか取り扱うメソッドを提供するのに対して、ユーザコンテンツタイプAPIではコンテンツ自体およびコンテンツのオーナーシップを取り扱うメソッドを含みます。私たちはこれらの異なるタイプのプラグインをコールすることができます。以下、いくつかの例です:

  • アーティファクト (artefact)プラグインタイプはユーザコンテンツを取り扱います (ユーザコンテンツのアイテムが「アーティファクト」呼ばれることが、この名称の由来です)。
  • 認証 (auth)プラグインにはユーザアカウントの正当性を確認するAPIがあります。
  • The ブロックタイプ (blocktype) プラグインタイプではシステムに新しいタイプのブロックを装着できる方法 (pluggable way) を提供します。

Mahara 1.1では次のプラグイン利用できます: 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

サブページ