ヘルパーがだめだめ

2007/03/05 | cakePHP

海外ではウェブのフォームで確認画面を出さないのはどうやらわりと一般的らしいが、少なくとも日本では一般的ではない。いくつかウェブを調べたら「確認画面なんていらないよね」といってる日本人技術者と思しき人たちはいるようだが、間違いなく彼らは間違っている。その真意には明らかに「ユーザビリティ考慮」の精神が欠けているからだ。どう転んでもウェブアプリのフォームで「確認画面をはさむ」という処理ははずせないのだ。
でもってcakePHP。いくら便利なscaffoldといってもデータ登録に確認画面はない。「入力=>完了」で終わりだ。ウェブを検索するとアプリのフレーム自動生成のbake.phpから出来たスクリプトを修正することで確認画面を実現されている方がいらっしゃった(こちら)。どうもこのページ、いろいろなサイトから参照されていて、cakePHPで確認画面を作る際の重要参考資料の位置づけとなっているようだ。こういうふうにスクリプトを惜しげもなく公開されていらっしゃる方には敬意を表します。
しかし・・・わざわざ確認画面用のビューを入力画面のとは別に作成しなくてはいけない。確認画面なんて入力画面とほとんど同じにもかかわらず、である。
今までmojaviを使っていたときはPEARのQuickFormを採用していたので、freeze()というメソッド一つで制御できていた。つまりフォームと確認画面のテンプレートを共通のファイル1つでまかなっていた。なんとかこれを実現したい。
作らなくてはいけないのは2つ。「コントローラー中での一般化された登録の仕組み」とヘルパー。仕組みはなんとなく今までの考え方をcakePHPに移植すれば出来そう。ヘルパーは現在のヘルパーを継承・拡張し、フォームがfreezeしたかどうかで表示を変更しさえすればよいはず・・・。
あと2日、cakePHPに時間を費やしてここまで作りたい。これを作って、さらに登録済み情報の編集機能を実装すれば、今後の開発はすべてmojaviからcakePHPに移行できる。
少し気合をいれて開発してみることにする(2日ということは細切れに時間を使って1週間くらいかかるということになりそうだけれど・・・)。

ファイルの構成

2007/03/04 | cakePHP

昨今ウェブアプリは「MVCパターン」という言葉でにぎわっているが、cakePHPでいうところのMVCとは以下のとおり。

[M]:モデル。データベース(テーブル)とかデータの構造について記述。
[V]:ビュー。表示(要は表示のためのテンプレート)のこと。
 表示の補助で使うスクリプトは「ヘルパー」とする。
[C]:コントローラー。処理手順を記述する。
 処理の補助で使うスクリプトは「コンポーネント」とする。

どこにどういうスクリプトを配置するのか、という場合の参考メモ。

データベースを使わない場合

2007/03/03 | cakePHP

cakePHPは基本的に(というかマニュアル上では)密接にデータベースと連携している。データベースと連携しているから、何も定義しなくてもテーブルの定義を読み取ってフォームやリストを作成してくれる。
とあるお客様から簡単なフォームの作成を依頼されたので、これをcakePHPでと思ったが、やり方がわからない(だってデータベース使わないから)。調べたら、やり方があった(元記事はcakephp.jp)。

(1)単純に静的なページを作りたい場合
「app/views/pages/」にhoge.thtmlなどとつくり、以下のようにアクセスする。
/pages/hoge
routes.phpの設定次第で、URLは如何様にもできる。

(2)モデル内で以下の記述をする。
「$useTable=false;」
「$useTable=null;」でもよいと書いてあったけど、こちらでは残念ながらNGでした。

一つ賢くなりました。

cakePHPはRORから

2007/02/26 | cakePHP

cakePHPは「Ruby on Rails」の流れを汲むフレームワークだ。はやっている言葉だから知ってはいたが、どういうものかはよく知らなかった(だって普通のレンタルサーバでRubyが使えるところなんてないから)。しかし最近諸々調べるにしたがって、かなりすばらしいツールであることがわかってきた。そのすばらしい点というのは「データベースにテーブルを作って、もとからあるクラスを継承しさえすれば(メソッドを何も書かずとも)ウェブアプリになってしまう」というところだ。そりゃ、こんなことができれば流行るわけだ。今日はそのことがわかった記念ということでちょっとメモ。
では、これをcakePHPで実現するには・・・ということになるのだが、まずは試してみた。
基本的にこのフレームワークはデータベース連携ありきだから、一例として本を管理するウェブアプリを作ることにする。最初は簡単なところで「書籍IDと本のタイトル」を管理することにする。
最初に書いてしまうと必要なのはデータベースのテーブル、モデルのクラス、コントローラーのクラスの3つだけでいい。表示とかは勝手にやってくれる。すごっ。
まずはテーブルの作成。cakePHPのルールの一つでテーブルのタイトルは英単語の複数形を使用するとのこと。その他クラスの命名規約等も考慮すれば、(いわゆるmojaviでいうところの)一つのモジュールを作るのにキーワードを一つ決めるのがよさそうだ。もちろん今回の場合は「book」になるだろう。で、テーブル名の話に戻るが、テーブル名は複数形を使用するらしい。だから必然的にここで利用するテーブルは「books」という名前になる。次にカラム名だが主キーは常に「id」という名前にしておく(ここでは書籍IDといったところか)。書籍名はまぁなんでもいいでしょう。これでテーブルはOK。ちなみに以下のSQLでテーブルを作成した。

create table books (id varchar(32) primary key,title text);

次にモデルを作成する。配置場所は(ドキュメントルート)/app/models/。ここにbook.phpという名前でモデル用のファイルを作成する。

<?php
class Book extends AppModel {
var $name = ‘Book';
}
?>

たったこれだけ(モデルは単数形で作る)。何にも考えなくていい。AppModelクラスを継承するだけでいい。あとクラス名の頭を大文字にしてることくらいか・・・。

次にコントローラー。こっちは複数形にする。配置場所は(ドキュメントルート)/app/controllers/。ファイル名はbooks_controller.phpとして以下の内容を記述する。

<?php
class BooksController extends AppController
{
var $scaffold;
var $name=’Books';
}
?>

こちらもたったこれだけ。唯一「$scaffold」というのがミソで、これを指定することによって、あらかじめcakePHP内で用意されているデータの一覧表示、追加、修正、削除機能をそのまま利用できるようになるとのことだ。

で、実際にアクセスする際には以下のURLをたたく(ここは複数形)。
http://(サーバ名)/books

たったこれだけ。これだけで最低限のウェブアプリが出来てしまう。普通はなかなか、このまま使うのは難しいかもしれないけど、なんらかの管理画面なら結構このまま使えてしまうはず。
サンプルアプリの勉強は、この$scaffoldからはじめるのがよさそうだ。ちなみにこの言葉の意味は「足場、断頭台」。う〜む。なんかいいネーミングだね。

サンプルアプリの導入

2007/02/24 | cakePHP

とりあえず何をどうしていいかわからない。こういうときは実践あるのみ。サンプルアプリケーションを動かしてみることにした。使用したのは以下のさいとにある掲示板サンプル。
http://puyo2.upper.jp/cake/

ソースをダウンロードして解凍後、その中のREADME.TXTに記述のあるとおりにインストールした。あとREADME.TXTにあるテーブルの定義から、そのままテーブルを作成した。もちろん最初に設定したデータベース内にテーブルを作成した。これでインストールは終わり。

で、動かしてみた。
書き込みはできたっぽいけど、表示でエラーが出る。エラーの内容は・・・「その配列にはあなたが指定したindexはありませんよ」とのこと。むむむ。
サンプルのソースを見れば簡単。$row[‘forum’]と指定されているところを$row[‘Forum’]と書き直すことで無事動作した。

ソースを見たけどまったくシンプル。「もちろん」というかすごいのはSQL文が書かれていないこと(自分としてはSQL文あったほうがなんとなく今迄っぽくていいのだけれど)。
今度はこのソースを読んで、噛み砕いていきたい。

しかし・・・このサンプル、「confirm.thtml」なんてファイルがあるから「確認画面もつかってるのか!」と思ったら「確認と見せかけて、書き込み官僚」だって(「官僚」って・・・誤字じゃん・・・)。少し期待したんだけどね。


守谷市(まちの情報ポータル) 無料アンケートレンタルjpForm.net