Jeans CMS 製作日記 自分のための次世代CMS製作メモ

Jeans CMSで、コア・プラグインを書くときの規約（案）

１）グローバル変数、グローバル関数は利用しない（スーパーグローバルは除く）。

２）include, require, include_once, require_once は使用しない（index.php, config.php, core.php を除く）。

３）echo, print は使用しない（core.php を除く）。HTMLタブを出力するときは『core::echohtml()』を、タブ以外を出力するときは『echo::p()』を利用する。

４）SQLクエリーを作成するときは、『sql::fill()』もしくは、『sql::query()』の、フィリング機能を利用する。

５）『sqlite_query()』などのデータベース関連関数は直接利用せず、代わりに『sql::query()』などを利用する（sqlite.phpは除く）。

６）SQLiteでクエリー用の関数を作成する場合、原則としてMySQLやPostgreSQLなどでも利用できるものを使う。ただし、SQLiteの機能を最大限に利用するようなプラグインを作成する場合はこの限りではない。

７）プラグイン名は『jp_』から始まり、英数字のみ（アンダースコアは含まない）。『jp_プラグイン名_クラス名』という名のクラスを『jp_プラグイン名_クラス名.php』というファイル名で記述し、このphpファイルをプラグイン管理領域におけば、インクルードはコアが自動的に実行してくれる。

１－４は、セキュリティ関連。１３４については、この規約に従っても問題なくプログラミングできるような環境はすでにできあがっている。２についてもほぼできあがっていて、ファイルのインクルード＝クラスの読み込みととらえることで、__autoload()関数により、自動的にインクルードが行われる。これらの規約に従って書くことで、セキュリティーチェックがずいぶん楽になると思う。

５６は、MySQL、PostgreSQLなどの対応を睨んだもの。SQLiteそのものはクエリーの文法がベーシックなので、ほかのデーターベースエンジンへの対応は難しくなさそう。ただ、SQLiteの便利なところは、異なるファイルを用いることで、テーブルごとにデーターベースを分けて使うことが出来ること。MySQLなどでも同様のことが出来るのであるが、レンタルサーバなどで環境に制約がある場合はこういったことは出来ない。SQLiteがあればそれを使うに越したことはないという仕様になると思われる。