今週もEthnaネタを。
ある人がすごくお待ちかねのネタだそうです。

概要

EthnaのViewをRailsとかにあるLayoutに対応させます。
これは結構いろんな人がやっているようです。その一つということで。

Source

http://bobpp.as-roma.com/svn/ethnaLibs/trunk/projBop_Layout_ViewClass.php
こちらになります。

使い方は続きをみてね。

» 続きを読む

昨日公開したEthna_AppObjectでHasManyや、来週公開予定のライブラリの資料を書いてみて思うのだけど、昔書いたコードはデフォルト値の指定がまだまだ甘いなと感じる。
もっと簡単に書けるように改修できそうな気がしてきたので、再来週はそれをやろうかな。

久々のEthnaネタです。
まだいくつかネタがあることが判明しましたので、徐々に公開していこうと思います。

AppObjectでRailsのActiveRecordでいうBelongsTo/HasOne/HasMany/HasAndBelongsToMany/HasManyThroughを実装してみました。
HasManyThroughはすごく不完全のようです。
AppObject再編が騒がれているこのタイミングというのも何かの縁でしょう。完全にその再編で思い出しただけなんですが。

ただ、だいぶ昔のバージョンでしか試していないのが若干不安です、しかし一応世の中に出しているサービスで稼働中の実績もあります。
この辺の名前は出していいのかわからないので、いったん自重しておきます。

Source

ついに、こういうライブラリもsvn管理になりました。
http://bobpp.as-roma.com/svn/ethnaLibs/trunk/projBop_AppObject.php
こちらになります。ほかの機能もいくつか混ざっているようですが、それは追って紹介していこうと思います。

使い方は続きをどうぞ。

» 続きを読む

最近、XREAのサーバにEthnaのアプリケーションを設置して、思いのほかやりやすい方法で設置できたので、メモを兼ねて。
Ethna自体やPEARのインストールについては、以前書いた記事が参考になるかと思います。(参考: BoBlog >> XREAでPEARコマンド)

また、かなり当たり前な方法をやってるだけなのだけど、XREAでもこれが出来るとは思ってなかったので･･･。

1. エントリポイントを修正

通常Ethnaの add-project等で生成されたエントリポイントのファイルには、APPID_Controller.phpのパスがフルパスで書かれています。
今回はそれを相対パスに変更しておきます。通常のディレクトリ配置であれば、
require_once '../app/APPID_Controller.php'; このような形でしょうか。

2. FTPでアップ。

FTP等で通常のディレクトリ構成のままユーザが触れる最初のディレクトリにアップロードします。
また、tmp, log等のディレクトリにはもちろんApacheでの書き込み権限を付加します。

最終的な構成としては、

(/virtual/UserID)
├ APPID (Ethnaのプロジェクト)
│  ├ app
│  ├ bin
│  略
│  └ www
│        └ index.php
├ log
└ public_html

以上のようになるかと思います。

3. (ドメイン利用時) ディレクトリを作らない

何かしら自分で取得したドメインを利用される際に、ドメインウェブの設定がまだ済んでいない場合は、対象のディレクトリ (hoge.example.com)であれば、hoge.example.comディレクトリを作成しないオプションを利用して、設定することをお勧めします。
また、すでにドメインウェブの設定が済んでいて、ディレクトリが完成している場合は、すでにデータがないかを確認してからサクッと削除してください。

4. シンボリックリンクを張る

あとはシンボリックリンクを張ってしまえばOKかと思います。

今回は、hoge.example.com上に展開したいとします。
$ ln -s /virtual/<i>UserID</i>/<i>APPID</i>/www/ /virtual/<i>UserID</i>/public_html/hoge.example.com/
こんな感じです。

5. 確認して、コーヒーを飲む。

5ステップもあるので、コーヒーを飲まなくてもいいかもしれませんｗ

上記の方法を使えば、意外にさっくり設置できるかなと思います。

最初に。

ゴメンナサイ。v.0.3.0は相当不完全でした。
その修正もあるので、今回のアップデートはぜひ適用してください。

ダウンロード

http://as-roma.com/ethna/ethcaffold/Ethcaffold-0.3.1.tar.gz
こちらからダウンロードしてください。

インストール

Ethcaffoldのインストール・使い方やEthcaffoldとは？については、Ethcaffoldのまとめ記事 (参考: BoBlog >> Ethcaffold まとめ)をお読みください。

変更点

• そもそも v.0.2系のままっぽい ゴメンナサイ ゴメンナサイ
• makeUnitTestCaseプラグインがインストールされている場合は、モデルのテストケースを作成する機能を追加
• フォームにて、主キーの変更等が出来ないように変更

などです。

今回のEthcaffoldで、UnitTestCaseとの連携が取れるようになりましたので、TDDっぽい開発等もかなりやりやすくなっていくのではないかと思います。
また、バグ･要望等ありましたら、ぜひぜひ教えてください。

ブログをうちからはてなに移動したばかりの元CTOブログにこんな表記が。

てつじんにっき - EthnaでUnit Test その１

Ethnaのデフォではadd-action-test,add-view-testといったコマンドしか用意されてませんが、AppManagerやAppObject、Pluginなんかに対してもテストを書くことができます。

個人的にそういったロジックレベルでのテストケースのほうがよく書くし、大事かなぁとか思います。

そういったのを簡単に作れるEthnaコマンドがあれば*1便利だなぁ…。

*1：近いうちBoBppさんがリリースしてくれるような気がします。(ムチャフリ

勝手に移動しといてどういう了見だというのはいいとして(笑)、せっかく振られたので公開してみます。

http://as-roma.com/ethna/makeUnitTestCase/makeUnitTestCase-0.1.0.tar.gz
UnitTestCaseのファイルを作成するHandle等です。

インストール

インストールはEthcaffoldと同じで、Ethna本体が入ってるところに突っ込みます。
パッケージ化したほうがいいのはわかってますので、いずれｗ

使い方

使い方はいたって簡単で、
$ ethna add-unit-test-case <CaseName> です。作成したいテストケース名を引数にすればOKという単純構成です。

Ethcaffoldとの連携

次のEthcaffoldのリリースでは、このプラグインが導入されていれば自動的にモデルに対するテストケースファイルを作成する機能を用意する予定です。

また、バグや要望があればコメント等でお待ちしてます。

久しぶりのリリースです。

Ethcaffold v.0.3.0です。
http://as-roma.com/ethna/ethcaffold/Ethcaffold-0.3.0.tar.gz
Ethcaffoldはv.0.3.1にアップデートしました。というか、0.3.0はかなり使えないのでアップデートしてください。

Ethcaffoldの使い方やEthcaffoldとは？については、Ethcaffoldのまとめ記事 (参考: BoBlog >> Ethcaffold まとめ)をお読みください。

今回は

• 各モデルごとのActionFormクラスを/app/action_formに生成する
• カラム名の定義ファイルを/app/column_nameに生成する

といった変更が行われました。

バグや要望があれば教えてください！お待ちしてます。

最近思いっきり放置しているEthcaffoldですが、多少は今後のことも考えているので今回はそのことでも。

次期リリースは0.3.0になる予定です。実際に、現在行っている会社では0.3.0を使ってもらっていて問題なく使えているので、そろそろリリースしようかなと思います。
具体的な変更点としては、
・ActionFormのフォーム定義を各モデルごとのActionFormクラスを生成しそのform_templateに出した
・カラム名等の定義を別ディレクトに追い出した
となります。
この二つによって、前よりDRY度が増すかなと考えております。

0.4系では、LayoutViewの組み込みを考えています。
Railsでも、また弊社でもScaffoldingしたファイルを修正してアプリケーションを作っていくこともありますので、Layoutの仕組みを入れて見た目の変更をより容易にしたいと考えています。

0.5系では、相当先のリリースになるかと思いますが、Action等のファイル生成を行わない、InnerScaffold(と勝手に命名)の実装が出来たらと考えています。
こういう形式のScaffoldも一定の需要があると予想されるため、将来的に対応できればと思います。
また、それに向けてアイディアを練っている途中です。


そんな形でEthcaffoldも進化を続ける予定です。Ethcaffoldに関して、要望等があればぜひ教えてください。

同じようなサイトをデザイン違いで複数持ちたいときがあるとします。
しかし、安易にこれをコードコピペとかで開発するのは何かあったときにマージするのが面倒だし、バージョン管理するときにリポジトリが複数になってさらに面倒です。
マージが面倒だと、保守性が一気に下がってしまいテンションガタ落ちです。

そこで、Ethnaでエントリポイントとテンプレートを分けることで複数サイトを作成する手法をご紹介します。(というか最近そういうのをやってるだけ)

エントリポイントを追加

www_subとかを追加します。

<<略>>

├ tmp

├ www/ (メインサイト)

│	├ img/

│	├ css/

│	├ js/

│	└ index.php

└ www_sub/ (サブサイト)

	├ img/

	├ css/

	├ js/

	└ index.php

こんな感じですね。

そして、サブサイトのほうの www_sub/index.php のAPPID_Controller::mainを呼ぶ前に何か定数を宣言してください。値はtrueとかでいいです。
define('SITE_MODE_SUBSITE', true); こんな感じですかね。

テンプレートのディレクトリを追加

上と同じような形でディレクトリを追加します。

<<略>>

├ template

│	├ ja/ (メインサイトのテンプレート)

│	│	└ index.tpl

│	└ ja_sub/ (サブサイトのテンプレート)

│		└ index.tpl

├ tmp

<<略>>

こういう形になりますか。

ja/ にはメインサイトとなるサイトのテンプレートを。
ja_sub/ にはサブサイトとなるサイトのテンプレートを通常の手順どおり書いていってください。

Controllerを修正して複数サイトに対応

APPID_Controllerのファイルを編集しEthna_Controller::getTemplatedirをオーバライドします。
function getTemplatedir()
{
  $template = parent::getTemplatedir();
  if (defined('SITE_MODE_SUBSITE') {
    $template .= "_sub";
  }
  
  return $template;
} 上記のようにすることで、エントリポイント追加時に設定した定数の有無でテンプレートディレクトリを分けることが出来ます。

応用すれば二つといわず大量の似たサイトも作ることが出来るでしょう。

おまけ・エントリポイント上のファイルがそっくり

JavaScriptのファイルがほぼ同じとかでエントリポイントも･･･。というときは、シンボリックリンク張れ。
といいたいところですが、やっぱりリポジトリ周りがうざいので、ちょっと対策を考えてみましょう。

ここでは、Configを利用します。
Ethna 2.3.xから、URLHandler等を用いるためにUrlの設定がConfigで出来るようになりました。
また、そのConfigで設定した値はテンプレート上で用いることが出来ます。
そこで、
// 環境ごとの配置設定
// MainSite
if (defined('SITE_MODE_SUBSITE') === false) {
  define ('URL', 'http://localhost/appid/www/');
  define ('IMG_PATH', URL . 'img/');
  define ('CSS_PATH', URL . 'css/');
  define ('JS_PATH', URL . 'js/');
  
// SubSite
} else {
  define ('URL', 'http://localhost/appid/www_sub/');
  define ('IMG_PATH', URL . 'img/');
  define ('CSS_PATH', URL . 'css/');
  define ('JS_PATH', 'http://localhost/appid/www/js/');
}

$config = array(
  // site
  'url' => URL,
  'img_path' => IMG_PATH,
  'css_path' => CSS_PATH,
  'js_path' => JS_PATH,

); 上記のようにこれまた例に倣って定数の有無でURL等を分けます。また、img_path, css_path, js_pathを追加しました。

そしてテンプレート上で、、、
<script type="text/javascript" src="{$config.js_path}hoge.js"></script> このような形で読んであげれば変更が自由自在になります。

横展開しそうなシステムを作ってる方でソースの管理にお悩みの場合はぜひ試してみてください。

画像アップロードに関するvalidatorプラグインです。誰か作ってるという噂もあったのですが
なお、gd必須です。ソースファイル等はこちらから。

以下使い方です。

単純に画像であるか検証する

var $form = array(
  'image' => array(
    'type' => VAR_TYPE_FILE,
    'form_type' => FORM_TYPE_FILE,
    'name' => "がぞう",
    'image' => true,
  ),
); このような形式です。imageプラグインをtrueにしておけばgd上で画像と判定できればチェックを通過します。

横幅をチェック対象に加えたい

たまにサイズ指定したいときありますね。
var $form = array(
  'image' => array(
    'type' => VAR_TYPE_FILE,
    'form_type' => FORM_TYPE_FILE,
    'name' => "がぞう",
    'image' => true,
    'image_width' => 100,
  ),
); image_widthに横幅の許容最大px数を入れておけばOKです。

高さをチェック対象に加えたい

横幅とほぼ同じです。
var $form = array(
  'image' => array(
    'type' => VAR_TYPE_FILE,
    'form_type' => FORM_TYPE_FILE,
    'name' => "がぞう",
    'image' => true,
    'image_height' => 100,
  ),
); image_widthがimage_heightになっただけです。

画像の種類をチェック対象に加えたい

jpegだけとかそういうことです。
var $form = array(
  'image' => array(
    'type' => VAR_TYPE_FILE,
    'form_type' => FORM_TYPE_FILE,
    'name' => "がぞう",
    'image' => true,
    'image_types' => array(
      IMG_JPEG, IMG_GIF, IMG_PNG,
    ),
  ),
); 上記のようにimage_types配列にgdで定義されている画像の種類に該当する定数を並べておけばチェックしてくれます。

なお、すべてにいえることですがGDのgeteimagesize() で調べられない画像ファイルに関しては弾いちゃいますのでご注意ください。

エラーメッセージを変更したい

通常のvalidatorプラグインと同じように・・・
var $form = array(
  'image' => array(
    'type' => VAR_TYPE_FILE,
    'form_type' => FORM_TYPE_FILE,
    'name' => "がぞう",
    'image' => true,
    'image_error' => "がぞうがいいなぁ",
    'image_width' => 640,
    'image_width_error' => "もっと幅を小さくしてほしいなぁ",
  ),
); 上記のように～_errorにエラーメッセージを入れればその文言が表示されるようになります。

ということでバグ報告とか要望とか、どしどしお待ちしてます！