CakePHPを業務に導入する Shin x blog 新原　雅司.

Presentation on theme: "CakePHPを業務に導入する Shin x blog 新原　雅司."— Presentation transcript:

1 CakePHPを業務に導入する Shin x blog 新原　雅司

2 自己紹介 新原雅司（しんばら まさし）といいます。 大阪でWeb系開発をやってます。
新原雅司（しんばら　まさし）といいます。 大阪でWeb系開発をやってます。 Shin x blog という blogを書いてます。 CakePHPガイドブックを共著しました。 =>ありがとうございます。

3 Agenda 導入する [プログラマ編] 導入する [デザイナ編] 導入する [PM編] 導入してみて

4 導入する [プログラマ編] bake 基本を抑える セキュリティ 既存資産

5 bake 簡単 でも面倒 実際使っていない 生成されるコードはそのままは使えない 自分で書いたソースをコピーして使用 サンプルソース

6 基本を抑える MVCやコンポーネント・ヘルパは便利 それだけで全てが構築出来るほど 単純ではない
フレームワークのルールの中で PHPの基本処理をどのように行うかを掴む

7 基本を抑える - GET/POSTパラメータ
Controller#$paramsに値を保持 <?php // $_GET $this->params[‘url’] // $_POST $this->params[‘form’] ?>

8 基本を抑える - Session SessionComponent Controllerでは$componentsで設定なしで使用できる

9 基本を抑える - Cookie 1.1は$_COOKIE => コンポーネントは無い 1.2はCookieComponet

10 基本を抑える - ビューでフォーム値取得 ヘルパがそのまま使えない時もある => 携帯とか フォーム値だけ取得してあとはHTMLを書く
1.1ならHtmlHelper#tagValue() 1.2ならHelper#value() <input type=“text” value=“<?php echo h($html->value()); ?>” /> <input type=“text” value=“<?= h($html->value()) ?>” />

11 基本を抑える - DB SQLを直接実行 Model#query()かDboSource#execute() <?php
Class HogeController extends AppController { function foo() { $sql = “insert into hoges select name,status from foos;”; $this->Hoge->query($sql); } ?>

12 セキュリティ XSS/CSRF/SQL Injection
$this->dataはそのまま使わない => 外部から来る値は信用しない find/findAll系では演算子インジェクションに注意

13 既存資産 ライブラリなどの既存資産は上手く利用 => 全てをCake用に作り直さなくて良い
vendors/ or app/vendors に設置 vendor()で読み込む コンポーネントでラップする

14 まとめ 基本はこれまでの開発と同じ フレームワークに固執し過ぎない => 泥臭い方法で対処することもある
その上で楽できるところは上手く使う

15 導入する [デザイナ編] ビューテンプレート MVC エラーメッセージ

16 ビューテンプレート – 拡張子 拡張子を「.html」にする Controller#extを変えるだけ <?php
class AppController extends Controller { public $ext = ‘.html’; } ?>

17 ビューテンプレート – レイアウト レイアウトとビューテンプレートに 分かれている
ビューだけにする => レイアウトではビューテンプレートを 出力するだけ [app/views/layouts/default.html] <?php echo $content_for_layout;?> <?php echo $cakeDebug?>

18 MVC URLと出力されるファイルが異なるのが 飲み込めない人がいる 慣れてもらうしかない。。。
/hoge/foo で表示されるのに/hoge/fooというファイルが無い /hoge/fooファイルを設置すると動かなくなった .phpは無くても良いの？ 慣れてもらうしかない。。。

19 エラーメッセージ ビューテンプレートに直接書く プログラマ以外でも文言を変更できる
1.1ならHtmlHelper#tagErrorMsg() 1.2ならFormHelper#error() プログラマ以外でも文言を変更できる

20 まとめ デザイナの負担を軽くする メリットを説明する ビューにSmartyを使う方法もある

21 導入する [PM編] 増えるコスト 減るコスト

22 増えるコスト 学習コスト （場合によっては）移行コスト

23 減るコスト フレームワーク作成 フレームワークメンテナンス 教育コスト

24 まとめ 初期学習コストを考えてもメリットはある => 教育・メンテナンス PHP5移行期の今なら特に => PHP4/5対応
Rails風フレームワークなので習得した技術はムダにならない

25 導入してみて 初期学習コストはかかった ノウハウが共有できる フレームワークのソースは読む必要はある
生産性が見違えるように上がるわけでは ない => オレオレFW

26 1.1か1.2か 1.1実績があるなら1.1で これからなら1.2で ※現在開発中の案件は1.2で進行中

27 ご静聴ありがとうございました Happy baking!!