このドキュメントはLoggix API Documentationを読み進める開発者のための事前知識としてのLoggixの開発コンセプトとAPI(アプリケーションプログラミングインターフェイス)の補足解説です。

Loggixのコアクラス

Loggixシステムの基幹部分を構成するクラス群です。/lib/Loggix/ディレクトリ直下に配置されるクラス及び関数ファイル群のことを指します。Loggix API Documentationでのパッケージ名が「Loggix_*」になっているものがこれにあたります。

  • lib
    • Loggix
      • Application.php
      • Core.php
      • Expander.php
      • Plugin.php
      • Utility.php
      • View.php

Loggixのモジュールクラス

Loggixのモジュールクラスとは、/lib/Loggix/Module/ディレクトリに配置して機能拡張を実現するクラスライブラリのことを指します。標準ではいくつかのモジュールが入っています。このディレクトリに配置されたモジュールはLoggixアプリケーションが生成されるときに自動的にロードされるようになっています。標準モジュールを削除して自分で改造・開発したモジュールを追加したり出来ます。

  • lib
    • Loggix
      • Module.php
      • Module
        • Calendar.php
        • Comment.php
        • Helloworld.php
        • Rss.php
        • Trackback.php

Loggix_Module継承クラスの開発

新規にLoggix_Moduleクラスを継承してクラスを開発する場合は以下のルールに従って行います。

  1. 継承クラスは特に明確な目的が無い限り、Loggix_Moduleクラスを継承して下さい。Loggixのコアクラス群が提供する全てのメソッドにアクセス出来るようになります。
  2. ファイル名はクラス名と同じにし、他のクラスと重複するのを避けるために必ず接頭辞を付けます。(開発の例参照)
  3. Loggixにデフォルトで含まれるLoggix_Moduleの接頭辞は「Loggix_Module_」としていますが、これは「Loggix_Moduleをextends(継承)している」ことを表しています。(サードパーティ製のモジュールは改名せずそのまま同梱しています。)　このように、Loggix_Moduleを継承して開発するモジュールの接頭辞は基本的に「Loggix_Module_」とするもの、とします。
  4. モジュールはclassを使ってのパッケージ化を推奨します。
  5. モジュールの返す変数は必ずクリエイターコードを第一グループ変数として含めます。
    $module['LM']['foo']
    Loggix Projectが標準で添付しているモジュールのクリエイターコードは「LM」(LOGGiX Module)となっています。Loggix Project以外の開発者が作る場合はこれと重複しないクリエイターコードを命名するのが望ましいです。クリエイターコードは大文字でなるべく短いものを推奨とします。クリエイターコード内で単語を区切る場合は「_(アンダースコア)」を使用します。
  6. 推奨される標準コーディング規約に従ってコーディングを行って下さい。

開発の例

例えば以下のような「Example」というクラスを作る場合、ファイル名と配置は以下のようになります。

  • lib
    • Loggix
      • Module
        • Example.php (モジュールクラスファイル)

コード内でのクラスの命名はこのようになります。

1
2
3
4
5
6
7
8

<?php
class Loggix_Module_Example extends Loggix_Module
{
    public function getFoo()
    {
        return $module['LM']['foo'] = 'Foo';
    }
}

Loggix_Moduleクラスを利用して作成したコンテンツモジュールの配置

Loggix_Moduleを利用して作成したコンテンツモジュールは基本的にLoggixのメインディレクトリ構成と同じ構成となるものとします。「modules」ディレクトリに以下のように配置します。

  • modules
    • example (接頭辞なし小文字)

モジュールは便宜上/modules/以下に配置することを基本としますが、ディレクトリ配置はURI名に関わる部分ですので、ユーザーによっては「/modules/」がモジュールのアドレスの前につくのを嫌う場合があるかもしれません。その場合は/modules/以外の場所に配置することも可能です。(その際はライブラリを読み込むパスの記述に注意して下さい)

標準コーディング規約

Loggixのモジュール開発は、以下のコーディング規約に準拠して下さい。

複数のコーディング規約を採用している理由

上記のコーディング規約は敵対するものではなくお互いの不足部分を補うことが出来るという考えからです。例えばPEARのコーディング規約ではグローバル変数の命名規約はありますが、通常の変数の記述スタイルまでは明記されていません。(↓)

If your package needs to define global variables, their name should start with a single underscore followed by the package name and another underscore.

PEAR :: Manual :: Naming Conventions

パッケージでグローバル変数を定義する必要がある場合、その名前は、 アンダースコアを前後に付けたパッケージ名で始めるべきです。

PEAR :: Manual :: 命名規約

対してZend Frameworkの規約ではグローバル変数の指定は記述されておらず、クラスのメンバー変数では"private"や"protected"はアンダースコアで開始し、変数は関数名と同様にキャメルキャプススタイルで記述する、と書かれています。

For class member variables that are declared with the "private" or "protected" construct, the first character of the function name must be a single underscore. This is the only acceptable usage of an underscore in a function name. Member variables declared "public" may never start with an underscore.

("private"や"protected"で定義されたクラスメンバー変数名、関数名はアンダースコア(_)で開始しなければいけません。関数名でアンダースコアの使用が認められる唯一の例です。"public"で定義されたメンバー変数名はアンダースコアで開始してはいけません。)

Like function names (see section 3.3, above) variable names must always start with a lowercase letter and follow the "camelCaps" capitalization convention.

(関数名と同様、変数名も小文字で開始し、camelCapsスタイル(単語の区切りを大文字にする)を使って命名します。)

Zend Framework: Manual

このようにお互いに欠けている部分をうまく補う事でより汎用的で可読性と品質の高いコードが保てると考えます。