アクションコントローラーの保存を多階層化 - noopな日々
アクションコントローラーの保存を多階層化して、多数のコントローラーを整理できるようにした。 Zend_Controller_Dispatcher_Standardのコントローラー名解決でサブディレクトリ仕様にしてみた。 Zend_Controller_Dispatcher_Standardを継承したクラスを作って、 _formatName内で下記のように一行変更する。 <?php // $segments[$key] = str_replace(' ', '', ucwords($segment)); $segments[$key] = str_replace(' ', $this->getPathDelimiter(), ucwords($segment)); あとは、フロントコントローラーにsetDispatcherでnewして注入するだけ。 /foo-bar/baz/ へのリクエスト
PHP製DIコンテナ"yadif"をZend_Applicationと共に使う - noopな日々
Zend_Applicationはフレームワークの設定と主要インスタンスの管理に使いますが、今のところモデル用のリソースがありません。 PHP製のシンプルなDIコンテナ"yadif"は設定によるオブジェクトの生成と管理が可能で、モデルの管理にも適します。ここでは、yadifを利用してサービスリソースを作成し、アプリケーションからモデルにシンボル名でアクセスできるようにします。 Zend_Applicationでのリソースの作成その他については、公式マニュアルに十分な解説がありますが、こちら(Zend_Application (5) 実戦的使い方 - noopな日々)でも書きました。 Yadif - Yet Another Dependency Injection Framework を使う GitHub - tsmckelvey/yadif: Yet Another (PHP) Depen
ZF勉強会#2フォローアップ Zend Frameworkでモデルを始める前に理解しておきたいこと - noopな日々
Zend Framework勉強会#2 はGMOペパボ株式会社様の協力もあって、盛況でしたが、どうもZend_Dbに関して誤解があるような気がしているので(私も含めて）一通り確認してみようというフォローアップ記事です。 Zend Frameworkで対応しているモデル構成は、ドメインモデル+サービスレイヤーで直接的にはデータマッパーです。 CakePHPでは標準ではActiveRecordを採用していると思いますが、ここがCakePHPやsymfonyで学習してきた人が一番最初に戸惑う部分ではないかと思います。また、初学者がデータマッパーの意義をいきなり理解するのは難しいような気もします。 要は、多くの初心者が“モデルって、DBテーブルのことだよね”と考えてしまうのはよくない、と。結果的にコントローラがふくれあがり、UnitTestで影響が出てしまう、という話になっています。 - Cake
文字列を配列扱いするとisset＋配列記法はtrueを返す - noopな日々
文字列を配列として扱うと、第2階層以降ではエラーになるのですが、第1階層だけはスライスしてくれるという仕様で微妙な動作をしているのでメモです。 http://d.hatena.ne.jp/noopable/20090726/1248589117 こちらで、よくあるPHPコードとして <?php $q = isset($_GET['q']) ? $_GET['q'] : NULL; こういうのを提示していましたが、似たソースで <?php $foo = isset($test['foo']) ? $test['foo'] : NULL; こんな感じでコードしてあったとします。$testのインデックスにfooがあるかどうかを調べて代入するというだけのコードですが、もし$testが文字列だと <?php $test = 'abc'; $foo = isset($test['foo']) ? $t
Zend_Application(2) /Zend FrameworkにおけるDIコンテナ活用のメリットについて/ - noopな日々
PHPでのDIコンテナのわかりやすい説明としては「最小のDIコンテナ in PHP」や「DIコンテナなんていらない」の中で説明されているし、DIコンテナをより詳細に推し進めた形としてはSeasar2のドキュメントか何かを見ていただいた方がいいと思います。DIコンテナは使いこまれた技術で基本概念や実装方法については知られていますので、ここでは、ZFを例にしてDIコンテナを使うメリットについて具体的に検討してみたいと思います。 Zend Frameworkを例にとると 前記事Zend_Application(1) - noopな日々で触れた下記のページにあるように、 http://www.infoq.com/jp/articles/drinking-your-guice-too-quickly DIコンテナはサービスロケーターから進化する流れがわかりやすいわけですが、それらを前提的な話として、
Zend_Application(1) - noopな日々
SVNに1.8のリリースタグが作られました。いよいよZend_Applicationがリリース待ちですね。 というわけで、試してみました。 マニュアル（英語版)はここでリリース済み、日本語版も間もなく出る？でしょう。 ファイルリストはこんな感じ Application.php Application │ │ Exception.php │ ├─Bootstrap │ Base.php │ Exception.php │ IBootstrap.php │ IResourceBootstrap.php │ ├─Module │ Autoloader.php │ Bootstrap.php │ └─Resource Base.php Db.php Exception.php Frontcontroller.php IResource.php Modules.php Session.php Vie
Zend_Cache_Backend_Fileの限界点 - noopな日々
ZendFrameworkのファイルをバックエンドとしたキャッシュは他のコンポーネントや拡張を必要としないのでお手軽に実施できます。 ただ、キャッシュエントリーが多くなるとキャッシュのクリアーなどで若干問題が発生するかもしれません。 複合的な要因で発生するようなので再現性や検証が難しいのですが。 事例：_cleanメソッド内でタイムアウト 高負荷なサイトでキャッシュの全クリアを実施したときに、Zend_Cache_Backend_File::_clean()のforeachループ内のis_fileとis_dirでタイムアウトして落ちるというケースがありました。（元々高負荷な状況ですので、30秒タイムアウトというのは余裕のあるラインではないのですが） 状況としてはユーザーリクエストで発生していたので、automatic_cleaning_factor による期限切れキャッシュなどの掃除が大量
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
