読者です 読者をやめる 読者になる 読者になる

Ethnaを業務で使うために(1) 雛形の準備

Ethnaは、phpの良さ(悪さ?)の手軽さや軽さを損なわずに、基本的なベース部分を肩代わりしてくれるいいフレームワークだと思います。
もちろん、手厚くいろいろしてくれたり、型にはまったものを早く作るために、他のフレームワークの良さもわかるのですが、融通の効き具合はいい感じだと思います。


実際に、1年半ほど前の2006年後半から使い出して、いまは特別な事情が無い限りメインのフレームワークとして使用して、キャンペーン系なども含めると数十サイトで使用してきました。
選考時点では、php4の環境がメインだったので、php4とphp5を対応しているのが条件だったのも判断のひとつではあったのですが。


せっかくなので、そこで溜まったノウハウの中で、一般的に役立ちそうなことを数回に分けて書いてみたいと思います。

Ethnaを業務で使う場合の工夫

業務でサイトを構築する場合、環境が複数あることになると思います。
・ローカルの開発環境(開発者が開発する環境)
・ステージング環境(確認環境)
・本番環境
dev環境やtest環境など名前はいろいろあると思いますが、複数環境に順次反映していくというのは一般的だと思います。
Ethnaの場合、環境に依存する部分があるので、そこに手を入れる必要があります。


また、ある程度、プラグインなど再利用できるものは、会社のノウハウとして貯めていかないともったいないので、毎回新規に作成するというわけにはいきません。
アプリケーションIDには、そのための仕組みが用意されているので、それも考慮してみたいと思います。


初回のみ ethnaコマンドの add-project を使用し、以降は、雛形を元に作成することにしています。
各案件で作成したプラグインなどは、再利用性を高めてテストした上で、雛形に追加していくことで、使いやすいカスタマイズされたEthnaが出来上がってくると思います。
また、そのようなプラグインは、どこでも必要になると思うので、共通の名前にして、みんなで共有していきたいです。

ここでは、Controllerのコメントにある Commonを採用してみます。

雛形の作成

まず、雛形のプロジェクトを作成するのだが、これはEthna本家サイトのインストールの準備が整っている前提です。
準備が出来ていない場合には、こちらを参考に環境を整えてくださいね。
Ethna - PHPウェブアプリケーションフレームワーク チュートリアル>インストール


アプリケーションを作成するディレクトリに移動し、ethnaコマンドを実行します。
アプリケーションIDは、雛形なのでcommonで作成します。

$ ethna add-project common
$ cd common

以下のようなディレクトリ構造のファイルが出来ています。
http://ethna.jp/ethna-document-tutorial-practice1.html#content_1_4

文字コード変更

文字コード変更は、EUC-JPのまま使用するのであれば必要ありません。
単純置換だと動かない機能もあるとのことなので、準備中のUTF-8版を待ってもいいかもしれませんが、いまのところ一括置換して使って大きな問題に遭遇していません。


作成されたファイルの一括変換。

$ find . -name '*.php' | xargs -n 64 nkf --overwrite -Ew


Ethna本体もUTF-8化して、libの下に自前で持ってしまいます。

$ cp -r /usr/local/lib/php/Ethna lib/

私の環境はphpをソースインストールなので、RPMなどで入れた場合には、パスが違うと思います。
最新版を手動で落としてきて設置してもいいと思います。
こちらも同じくEUC-JPをUTF-8に置換します。

$ find lib/Ethna/ -name '*.php' | xargs -n 64 nkf --overwrite -Ew
$ find lib/Ethna/ -name '*.tpl' | xargs -n 64 nkf --overwrite -Ew


自前で持ったEthnaを使うようにするために、app/Common_Controller.phpを修正します。
20行目のEthna.phpのインクルードを変更します。
変更前

/** アプリケーションライブラリのインクルード */
require_once 'Ethna/Ethna.php';

変更後

/** アプリケーションライブラリのインクルード */
require_once $lib . '/Ethna/Ethna.php';

これで、libの下のEthnaが使われるようになります。

ethna.shの作成

これだけだと、通常のethnaコマンドが使えなくなってしまうので、専用のコマンドをプロジェクトディレクトリに作成します。
ethnaコマンドのファイルをコピーし、ethna.shを作成します。

$ which ethna
/usr/local/bin/ethna
$ cp /usr/local/bin/ethna ethna.sh
$ ls
app  bin  etc  ethna.sh  lib  locale  log  schema  skel  template  tmp  www


ethna.sh の中を以下のように修正します。

#!/bin/sh
#
#   ethna.sh
#
#   simple command line gateway
#
#   $Id: ethna.sh,v 1.5 2007/01/04 06:23:15 ichii386 Exp $
#


ETHNA_HOME=$(dirname $0)"/lib/Ethna"

if test -z "$PHP_COMMAND"
then
    if test "/usr/local/bin" = '@'PHP-BIN'@'
    then
        PHP_COMMAND="php"
    else
        PHP_COMMAND="/usr/local/bin/php"
    fi
    export PHP_COMMAND
fi

if test -z "$PHP_CLASSPATH"
then
    PHP_CLASSPATH="$ETHNA_HOME/class"
    export PHP_CLASSPATH
fi

$PHP_COMMAND -d html_errors=off -qC $ETHNA_HOME/bin/ethna_handle.php $*

ETHNA_HOMEのパスの部分のみ変更です。
今後、ethnaコマンドを使用するときには、次のように使うことになります。

$ sh ethna.sh


これらの設定は、Ethna本体がEUC-JPだからなので、EUC-JPのまま使用するか、UTF-8化すれば不要だと思いますが、本番環境にPEARコマンドでEthnaインストールなどは、出来ない場合もあるので、同梱してしまった方が後々楽かもしれません。
また、PEARの特殊なものや、Smartyも同様にlibの下においてもいいかもしれません。

環境依存しているファイルの修正

次に、明らかに環境依存の箇所の修正と、公開しないほうがいいファイルを修正します。
ウェブサーバの公開ディレクトリ内のindex.php
私の環境では、以下のようになっています。このように環境依存のパスがそのまま入るのは、環境差異を吸収できないのでよくありません。

<?php
require_once '/home/maru/public_html/common/app/Common_Controller.php';

Common_Controller::main('Common_Controller', 'index');
?>

以下のように修正します。

<?php
require_once dirname(__FILE__) . '/../app/Common_Controller.php';

Common_Controller::main('Common_Controller', 'index');
?>

info.phpと、unittest.phpも、同じく修正します。
Ethnaの方でも、ここは始めから相対パスでファイルが作成されるようにしてもらいたいものです。

ディレクトリの変更

この中で、実際に運用時を想定し、あらかじめディレクトリ構造やファイルを変更しておきます。
テスト関連の本番公開時に公開ディレクトリにあるとよくないファイルを、他のディレクトリに移動します。
今回は、testディレクトを作成します。

$ ls htdocs/
css  index.php  info.php  js  unittest.php  xmlrpc.php
$ mkdir test
$ mv htdocs/unittest.php test/
$ mv htdocs/info.php test/

htdocs/xmlrpc.phpとか、css、jsディレクトリもデザインにあわせるべきなので、デフォルトで出来ているものは消しちゃいます。

$ rm www/xmlrpc.php
$ rm -r www/css
$ rm -r www/js

xmlrpc.phpを使う必要のあるアプリを作るならもちろん消す必要ないですからね。


次に、ウェブサーバの公開ディレクトリになるドキュメントルートの命名規則があるのならば、変更してしまいます。
うちの場合には、HTTP領域のドキュメントルートには「htdocs」、SSL領域のドキュメントルートは「htdocs.ssl」というルールなので、そちらに合わせて変更します。

$ ls
app  bin  etc  lib  locale  log  schema  skel  template  tmp  www
$ mv www htdocs
$ cp -r htdocs htdocs.ssl
$ ls
app  bin  etc  htdocs  htdocs.ssl  lib  locale  log  schema  skel  template  tmp

アプリケーションIDの変更

このままでは、今後作成するアプリ用のファイルが全てcommonになってしまうので、そこを修正します。
COMMONをアプリ用に変更します。うちでは、アプリケーションごとに変えるのではなく、固定文字にしています。
Common_Controller.php
42行目あたり
変更前

    /**
     *  @var    string  アプリケーションID
     */
    var $appid = 'COMMON';

今回は、「mm」としてみます。
変更後

    /**
     *  @var    string  アプリケーションID
     */
    var $appid = 'Mm';


161行目あたり
$plugin_search_appidsの値も変更しておきます。
変更前

    /**
     *  @var    array       検索対象となるプラグインのアプリケーションIDのリスト
     */
    var $plugin_search_appids = array(
        /*
         *  プラグイン検索時に検索対象となるアプリケーションIDのリストを記述します。
         *
         *  記述例:
         *  Common_Plugin_Foo_Bar のような命名のプラグインがアプリケーションの
         *  プラグインディレクトリに存在する場合、以下のように指定すると
         *  Common_Plugin_Foo_Bar, Common_Plugin_Foo_Bar, Ethna_Plugin_Foo_Bar
         *  の順にプラグインが検索されます。
         *
         *  'Common', 'Common', 'Ethna',
         */
        'Common', 'Ethna',
    );

変更後

    /**
     *  @var    array       検索対象となるプラグインのアプリケーションIDのリスト
     */
    var $plugin_search_appids = array(
        /*
         *  プラグイン検索時に検索対象となるアプリケーションIDのリストを記述します。
         *
         *  記述例:
         *  Common_Plugin_Foo_Bar のような命名のプラグインがアプリケーションの
         *  プラグインディレクトリに存在する場合、以下のように指定すると
         *  Common_Plugin_Foo_Bar, Common_Plugin_Foo_Bar, Ethna_Plugin_Foo_Bar
         *  の順にプラグインが検索されます。
         *
         *  'Common', 'Common', 'Ethna',
         */
        'Mm', Common', 'Ethna',
    );

とりあえず

雛形の元が出来ました。
まだ準備の途中ですが、長くなったので次回に続きます。