Previous Next

以前のバージョンからの移行

MVC コンポーネントの API は以前とは変更されました。 初期のバージョンから Zend Framework を使用しておられるかたは、 以下のガイドラインにしたがってスクリプトを変更し、 新しい仕組みに対応させてください。

1.7.x から 1.8.0 以降への移行

標準のルートの変更

新しい標準ルートでは翻訳セグメントが使用できるようになったため、 ルートのセグメントの先頭にある @ は特殊文字と解釈されるようになりました。 この文字を静的セグメント内で使用するには、前にもうひとつ @ をつけてエスケープする必要があります。 また、: も同様です。

1.6.x から 1.7.0 以降への移行

ディスパッチャインターフェイスの変更

ユーザからの指摘により、 Zend_Controller_Action_Helper_ViewRenderer が使っているディスパッチャ抽象クラスのメソッドの中で ディスパッチャインターフェイスに存在しないものがあることに気づきました。 次のメソッドを追加し、 自作のディスパッチャが同梱の実装と共存できるようにしています。

  • formatModuleName(): リクエストオブジェクト内に格納されたりしている生のコントローラ名を受け取り、 それを再フォーマットして Zend_Controller_Action を継承した適切なクラス名にします。

1.5.x から 1.6.0 以降への移行

ディスパッチャインターフェイスの変更

Zend_Controller_FrontZend_Controller_Router_Route_Module は、ディスパッチャインターフェイスにないメソッドを使用していました。 次の 3 つのメソッドを追加し、 自作のディスパッチャが同梱の実装と共存できるようにしています。

  • getDefaultModule(): デフォルトモジュールの名前を返します。

  • getDefaultControllerName(): デフォルトコントローラの名前を返します。

  • getDefaultAction(): デフォルトアクションの名前を返します。

1.0.x から 1.5.0 以降への移行

基本的な機能は同じでドキュメント化されている機能も変わりませんが、 ひとつだけ、ドキュメント化されていない "機能" が変更されました。

URL の書き方としてドキュメント化されている方法は、 camelCased 形式の名前のアクションを使用するために 単語の区切り文字を使用するというものです。デフォルトの区切り文字は '.' あるいは '-' ですが、ディスパッチャの設定で変更することができます。 ディスパッチャは内部でアクション名を小文字に変換し、 単語の区切り文字をもとに camelCasing 形式のアクションメソッド名を作成します。 しかし、PHP の関数名は大文字小文字を区別しないので、URL 自体を camelCasing 形式で書くこともできます。 この場合でも、ディスパッチャは URL を同じアクションメソッドに解決します。 たとえば 'camel-cased' はディスパッチャによって 'camelCasedAction' になります。一方 'camelCased' は 'camelcasedAction' となります。PHP では大文字小文字を細かく区別しないため、 これらはどちらも同じメソッドを実行することになります。

これは、ViewRenderer がビュースクリプトを解決する際に問題を引き起こします。 ドキュメントに記載されている正式な方法は、 単語の区切りをすべてダッシュに変換して単語は小文字にするというものです。 こうすればアクションとビュースクリプトの関連が明確になり、 小文字への正規化でスクリプトが見つかることが確実となります。 しかし、アクション 'camelCased' がコールされて解決された場合は、 単語の区切りはもう存在しません。そして ViewRenderer は 'camel-cased.phtml' ではない別のファイル -- 'camelcased.phtml' を探してしまうのです。

中にはこの "機能" を使用している開発者もいるようますが、 これは決して意図した機能ではありません。 1.5.0 のツリーでは、ViewRenderer はこの方式の解決を行わなくなりました。 これでアクションとビュースクリプトの結びつきが確実になったわけです。 まず、ディスパッチャはアクション名の大文字小文字をきちんと区別するようになります。 つまり、camelCasing 形式を使用したアクションの解決先は、 単語の区切りを使用した ('camel-casing') 場合とは違うものになるということです。 これで、ViewRenderer がビュースクリプトを解決する際には 区切り文字を使用したアクションのみを使用することになります。

今までこの "機能" に頼っていた人たちは、 以下のいずれかの方法で対応します。

  • 一番いい方法: ビュースクリプトの名前を変更する。 利点: 前方互換性。欠点: もし対象となるビュースクリプトが多い場合は、 多くのファイルの名前を変更しなければならなくなります。

  • その次にいい方法: ViewRenderer はビュースクリプトの解決を Zend_Filter_Inflector に委譲しています。 インフレクタのルールを変更し、 アクションの単語間をダッシュで区切らないようにします。

    $viewRenderer =
        Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
    $inflector = $viewRenderer->getInflector();
    $inflector->setFilterRule(':action', array(
        new Zend_Filter_PregReplace(
            '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
            ''
        ),
        'StringToLower'
    ));

    上のコードは、インフレクタを変更して単語をダッシュで区切らないようにしています。 もし実際のビュースクリプト名を camelCased にしたいのなら、さらに 'StringToLower' フィルタも削除することになるでしょう。

    ビュースクリプトの名前を変えるのが面倒だったり 時間がかかったりする場合は、 もしあまり時間を割けないのならこの方法が最適です。

  • あまりお勧めしない方法: ディスパッチャに camelCased 形式のアクションをディスパッチさせるよう、フロントコントローラのフラグ 'useCaseSensitiveActions' を設定します。

    $front->setParam('useCaseSensitiveActions', true);

    これで camelCasing 形式の URL を使えるようになり、 単語の区切り文字を使用した場合と同じアクションに解決されるようになります。 しかし、もともと抱えていた問題も残ったままとなってしまいます。 できれば先ほどのふたつのうちのいずれかを使用したほうがいいでしょう。

    このフラグを使用していると、 将来このフラグが廃止予定になったときに notice が発生することになります。

0.9.3 から 1.0.0RC1 以降への移行

1.0.0RC1 での最大の変更点は、 ErrorHandler プラグインと ViewRenderer アクションヘルパーが追加され、デフォルトで有効となったことです。 それぞれのドキュメントを熟読し、どのように動作するのかや 既存のアプリケーションに与える影響について確認しておきましょう。

ErrorHandler プラグインは postDispatch() で動作するもので、 例外をチェックして指定したエラーハンドラコントローラに転送します。 そのため、アプリケーション内にエラー処理用コントローラを含める必要があります。 このプラグインを無効にするには、フロントコントローラのパラメータ noErrorHandler を設定します。

$front->setParam('noErrorHandler', true);

ViewRenderer アクションヘルパーは、 アクションコントローラへのビューの注入を自動的に行います。 また、現在のアクションにもとづいたビュースクリプトを自動的にレンダリングします。 ビュースクリプトをレンダリングせず、かつ転送やリダイレクトも行わないアクションがあった場合、 これは問題になるでしょう。というのも、 ViewRenderer はそんなアクションであっても アクション名をもとに自動的にビュースクリプトをレンダリングしようとするからです。

もし既存のコードにそのようなものがあった場合の対応方法はいくつか考えられます。 一番手っ取り早いのは、フロントコントローラの起動時に ViewRenderer を無効にしてからディスパッチを行うことです。

// $front は Zend_Controller_Front のインスタンスであるとします
$front->setParam('noViewRenderer', true);

しかし、長い目で見ればこれはあまりよい作戦ではありません。 今後も新しいコードを書き続けるならなおさらです。

ViewRenderer の機能を把握したら、コントローラのコードを見てみましょう。 まず、アクションメソッド (名前が 'Action' で終わっているメソッド) を探し、その中でどんな処理をしているかを確認しましょう。 もし次に挙げるいずれの内容も行っていない場合は、コードに手を加える必要があります。

  • $this->render() のコール

  • $this->_forward() のコール

  • $this->_redirect() のコール

  • Redirector アクションヘルパーのコール

一番簡単なのは、そのメソッド内で自動レンダリングを無効にすることです。

$this->_helper->viewRenderer->setNoRender();

レンダリング、転送あるいはリダイレクトを行っているアクションメソッドがひとつもない場合は、 上で示したコードを preDispatch() メソッドあるいは init() メソッド内に書くといいでしょう。

public function preDispatch()
{
    // ビュースクリプトの自動レンダリングを無効にします
    $this->_helper->viewRenderer->setNoRender()
    // .. 何かほかのことをします...
}

もしメソッド内で render() をコールしていて、 規約どおりのディレクトリ構造 を使用しているのなら、自動レンダリングを使用するようにコードを書き換えましょう。

  • ひとつのアクションで複数のビュースクリプトをレンダリングしている場合は、 なにも変更する必要はありません。

  • 何も引数を指定せずに render() をコールしている場合は、 その行を削除します。

  • 引数つきで render() をコールしていて、 その後に何か処理をしたり複数のビュースクリプトを実行したりしていない場合は、 その行を $this->_helper->viewRenderer() のように変更します。

独自のディレクトリ構造を使用している場合は、 ビューの基底パスやスクリプトのパスをメソッドで設定してから ViewRenderer を使用します。これらのメソッドについての詳細は ViewRenderer のドキュメント を参照ください。

ビューオブジェクトをレジストリから取得していたり ビューオブジェクトをカスタマイズしていたり、 あるいはデフォルトとは異なるビューを使用している場合は、 そのオブジェクトを ViewRenderer に注入するために次のようにします。 これはいつでも好きなときに行えます。

  • フロントコントローラのインスタンスをディスパッチする前なら

    // $view はすでに定義されているものとします
    $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
    Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
  • 起動処理の中ならどこでも

    $viewRenderer =
        Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
    $viewRenderer->setView($view);

ViewRenderer を変更するにはさまざまな方法があります。 たとえばレンダリングするビュースクリプトを別のものに変更したり ビュースクリプトパスの置換可能な要素(サフィックスを含む) を置換する内容を指定したり、使用するレスポンスセグメントを選択したりなどのことができます。 規約どおりのディレクトリ構造以外を使用する場合は、 ViewRenderer でのパスの決定方法を変更することもできます。

ErrorHandler および ViewRenderer は今やコア機能として組み込まれているので、 既存のコードについてもできるだけこれに適合するようにすることをお勧めします。

0.9.2 から 0.9.3 以降への移行

0.9.3 では アクションヘルパー が利用できるようになりました。この変更にともない、以下のメソッドが削除され、 リダイレクタ アクションヘルパー に組み込まれました。

  • setRedirectCode() の代わりに Zend_Controller_Action_Helper_Redirector::setCode() を使用します。

  • setRedirectPrependBase() の代わりに Zend_Controller_Action_Helper_Redirector::setPrependBase() を使用します。

  • setRedirectExit() の代わりに Zend_Controller_Action_Helper_Redirector::setExit() を使用します。

ヘルパーオブジェクトの取得方法や操作方法についての詳細は アクションヘルパーのドキュメント を、 そしてリダイレクトの設定方法(新しいメソッドなど)についての詳細は リダイレクタ アクションヘルパーのドキュメント を参照ください。

0.6.0 から 0.8.0 以降への移行

前回変更された、もっとも基本的な MVC コンポーネントの使用法は、そのまま同じです。

Zend_Controller_Front::run('/path/to/controllers');

しかし、ディレクトリ構造を見直し、いくつかのコンポーネントが削除されました。 また、名前が変更されたり新たに追加されたものもあります。以下にそれらをまとめます。

  • Zend_Controller_Router は削除されました。 かわりに rewrite ルータを使用してください。

  • Zend_Controller_RewriteRouterZend_Controller_Router_Rewrite という名前に変わり、 このフレームワークの標準ルータに格上げされました。 Zend_Controller_Front は、 特に別のルータを指定しない限りこのルータをデフォルトで使用します。

  • rewrite ルータで使用する、新しいルートクラスが追加されました。名前は Zend_Controller_Router_Route_Module です。 これは MVC で使用するデフォルトのルートのほかに、コントローラモジュール をサポートしています。

  • Zend_Controller_Router_StaticRouteZend_Controller_Router_Route_Static という名前に変わりました。

  • Zend_Controller_DispatcherZend_Controller_Dispatcher_Standard という名前に変わりました。

  • Zend_Controller_Action::_forward() の引数が変わりました。 新しいシグネチャは次のとおりです。

    final protected function _forward($action,
                                      $controller = null,
                                      $module = null,
                                      array $params = null);

    $action は常に必須です。 コントローラを指定しなかった場合は、 現在のコントローラ内のアクションであるとみなされます。 $controller を指定しなかった場合は、 $module は常に無視されます。 最後に、$params で指定した任意の値が リクエストオブジェクトに追加されます。 コントローラやモジュールは不要だがパラメータは渡したいという場合は、 コントローラやモジュールに null を指定します。

0.2.0 以前のバージョンから 0.6.0 への移行

MVC コンポーネントの基本的な部分は変わっていません。 次のいずれの方法も使用可能です。

Zend_Controller_Front::run('/path/to/controllers');
/* -- ルータを作成します -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user',
                  'user/:username',
                  array('controller' => 'user', 'action' => 'info')
);

/* -- ルータをコントローラに設定します -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- コントローラのディレクトリを設定し、ディスパッチします -- */
$ctrl->setControllerDirectory('/path/to/controllers');
$ctrl->dispatch();

レスポンスオブジェクトを使用して、コンテンツとヘッダを取得することを推奨します。 これにより、アプリケーション内で より柔軟な出力書式の切り替え (たとえば XHTML ではなく JSON や XML を使用するなど) ができるようになります。 デフォルトでは、dispatch() はレスポンスのレンダリングを行い、 ヘッダとレンダリングされた内容の両方を送信します。 フロントコントローラから returnResponse() を使用してレスポンスを返し、レスポンスのレンダリングを独自に行うこともできます。 将来のバージョンのフロントコントローラでは、 レスポンスオブジェクトに出力バッファリングを使用する予定です。

これまでの API に加え、多くの機能が追加されています。 追加された機能についてはドキュメントを参照ください。

最大の変更点は、多くのコンポーネントで サブクラス化による拡張が可能になったことです。以下にポイントを整理します。

  • Zend_Controller_Front::dispatch() は、デフォルトでレスポンスオブジェクトの例外をトラップします。 例外の内容はレンダリングしません。これにより、 システムについての機密情報がレンダリングされてしまうことを防ぎます。 この挙動を変更するにはいくつかの方法があります。

    • フロントコントローラで throwExceptions() を設定します。

      $front->throwExceptions(true);
    • レスポンスオブジェクトで renderExceptions() を設定します。

      $response->renderExceptions(true);
      $front->setResponse($response);
      $front->dispatch();
      
      // あるいは
      $front->returnResponse(true);
      $response = $front->dispatch();
      $response->renderExceptions(true);
      echo $response;
  • Zend_Controller_Dispatcher_Interface::dispatch() は、ディスパッチャトークンではなく リクエストオブジェクト オブジェクトを使用するようになりました。

  • Zend_Controller_Router_Interface::route() は、ディスパッチャトークンではなく リクエストオブジェクト オブジェクトを使用するようになりました。

  • Zend_Controller_Action の変更点は以下のようになります。

    • コンストラクタが受け付ける引数は Zend_Controller_Request_Abstract $requestZend_Controller_Response_Abstract $response および array $params (optional) の三つになりました。 Zend_Controller_Action::__construct() は、これらを使用してリクエストやレスポンス、 そしてオブジェクトの invokeArgs プロパティを指定します。 コンストラクタをオーバーライドすることで、 この挙動をお望みのように変更することができます。 さらによいことに、init() メソッドを使用してインスタンスの設定を自由に行うことができます。 このメソッドは、コンストラクタでの処理の最後にコールされます。

    • run() は final メソッドではなくなりました。 しかし、このメソッドはもはやフロントコントローラでは使用されません。 これは、クラスをページコントローラとして使用する場合にのみ使用します。 オプションの引数 Zend_Controller_Request_Abstract $request および Zend_Controller_Response_Abstract $response を受け取ります。

    • indexAction() を定義する必要はなくなりました。 しかし、デフォルトのアクションとして定義しておくことを推奨します。 これにより、RewriteRouter とアクションコントローラで デフォルトのアクションメソッドを別々に指定できるようになります。

    • __call() をオーバーライドして、 未定義のアクションが自動的に処理されるようにする必要があります。

    • _redirect() にはオプションで二番目、三番目の引数が追加されました。 二番目の引数はリダイレクト時に返す HTTP コードです。 三番目の引数 $prependBase を使用すると、リクエストオブジェクトに登録したベース URL を URL の前に連結することを指示できます。

    • プロパティ _action は設定されなくなりました。 このプロパティの内容は Zend_Controller_Dispatcher_Token でしたが、これは現在のバージョンにはもう存在しません。 トークンの唯一の目的は、要求されたコントローラやアクション、 URL パラメータについての情報を提供することでした。 これらは現在はリクエストオブジェクトから次のようにして取得できるようになっています。

      // 要求されたコントローラ名を取得します。
      // その際には $this->_action->getControllerName() を使用します。
      // 以下の例では getRequest() を使用していますが、直接 $_request プロパティに
      // アクセスしてもかまいません。ただ getRequest() を使用することを推奨します。
      // とういのは、親クラスがこのメソッドをオーバーライドして挙動を変更しているかもしれないからです。
      $controller = $this->getRequest()->getControllerName();
      
      // 要求されたアクション名を取得します。
      // その際には $this->_action->getActionName() を使用します。
      $action = $this->getRequest()->getActionName();
      
      // リクエストパラメータを取得します。
      // これは変わっていません。_getParams() メソッドおよび _getParam() メソッドは
      // 現在は単なるリクエストオブジェクトへのプロキシです。
      $params = $this->_getParams();
      // パラメータ 'foo' を取得します。見つからなかった場合はデフォルト値 'default' を設定します
      $foo = $this->_getParam('foo', 'default');
    • noRouteAction() は削除されました。 存在しないアクションメソッドを扱うには、 __call() を使用してデフォルトのアクションに誘導します。

      public function __call($method, $args)
      {
          // 存在しない 'Action' メソッドが要求された場合に、
          // それをデフォルトのアクションに渡します。
          if ('Action' == substr($method, -6)) {
              return $this->defaultAction();
          }
      
          throw new Zend_Controller_Exception('無効なメソッド呼び出しです');
      }
  • Zend_Controller_RewriteRouter::setRewriteBase() は削除されました。かわりに Zend_Controller_Front::setBaseUrl() を使用してください (あるいは、リクエストクラスを使用している場合は Zend_Controller_Request_Http::setBaseUrl() を使用します)。

  • Zend_Controller_Plugin_InterfaceZend_Controller_Plugin_Abstract に置き換えられました。 すべてのメソッドは、ディスパッチャトークンではなく リクエストオブジェクト をやり取りするようになりました。

Previous Next
Introduction to Zend Framework
概要
インストール
Zend_Acl
導入
アクセス制御の洗練
高度な使用法
Zend_Amf
導入
Zend_Amf_Server
Zend_Application
導入
Zend_Application Quick Start
Theory of Operation
Examples
コア機能
利用できるリソースプラグイン
Zend_Auth
導入
データベースのテーブルでの認証
ダイジェスト認証
HTTP 認証アダプタ
LDAP 認証
Open ID 認証
Zend_Cache
導入
キャッシュの仕組み
Zend_Cache のフロントエンド
Zend_Cache のバックエンド
Zend_Captcha
導入
Captcha の方法
CAPTCHA アダプタ
Zend_CodeGenerator
導入
Zend_CodeGeneratorサンプル
Zend_CodeGeneratorリファレンス
Zend_Config
導入
動作原理
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
導入
Getopt の規則の宣言
オプションおよび引数の取得
Zend_Console_Getopt の設定
Zend_Controller
Zend_Controller クイックスタート
Zend_Controller の基本
フロントコントローラ
リクエストオブジェクト
標準のルータ
ディスパッチャ
アクションコントローラ
アクションヘルパー
レスポンスオブジェクト
プラグイン
モジュラーディレクトリ構造の規約の使用
MVC での例外
以前のバージョンからの移行
Zend_Currency
Zend_Currency について
通貨の操作方法
以前のバージョンからの移行
Zend_Date
導入
動作原理
基本メソッド
Zend_Date API の概要
日付の作成
日付関数全般用の定数
動作例
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
導入
Zend_Debug
変数の出力
Zend_Dojo
導入
Zend_Dojo_Data: dojo.data エンベロープ
Dojo ビューヘルパー
Dojoフォーム要素とデコレーター
Zend_Dom
導入
Zend_Dom_Query
Zend_Exception
例外の使用法
Zend_Feed
導入
フィードの読み込み
ウェブページからのフィードの取得
RSS フィードの使用
Atom フィードの使用
単一の Atom エントリの処理
フィードおよびエントリの構造の変更
独自のフィードクラスおよびエントリクラス
Zend_File
Zend_File_Transfer
Zend_File_Transfer 用のバリデータ
Filters for Zend_File_Transfer
以前のバージョンからの移行
Zend_Filter
導入
標準のフィルタクラス群
フィルタチェイン
フィルタの書き方
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Zend_Form クイックスタート
Zend_Form_Element を用いたフォーム要素の作成
Zend_Form によるフォームの作成
Zend_Form_Decorator による独自のフォームマークアップの作成
Zend Framework に同梱されている標準のフォーム要素
Zend Framework に同梱されている標準のデコレータ
Zend_Form の国際化
Zend_Form の高度な使用法
Zend_Gdata
導入
AuthSub による認証
Using the Book Search Data API
ClientLogin による認証
Google Calendar の使用法
Google Documents List Data API の使用法
Using Google Health
Google Spreadsheets の使用法
Google Apps Provisioning の使用法
Google Base の使用法
Picasa Web Albums の使用法
YouTube Data API の使用法
Gdata の例外処理
Zend_Http
導入
Zend_Http_Client - 高度な使用法
Zend_Http_Client - 接続アダプタ
Zend_Http_Cookie および Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
導入
Zend_Json
導入
基本的な使用法
Zend_Json の高度な使用法
XML から JSON への変換
Zend_Json_Server - JSON-RPCサーバー
Zend_Layout
導入
Zend_Layout クイックスタート
Zend_Layout の設定オプション
Zend_Layout の高度な使用法
Zend_Ldap
導入
Zend_Loader
ファイルやクラスの動的な読み込み
The Autoloader
Resource Autoloaders
プラグインのロード
Zend_Locale
導入
Zend_Locale の使用法
正規化および地域化
日付および時刻の扱い
サポートするロケール
以前のバージョンからの移行
Zend_Log
概要
ライター
フォーマッタ
フィルタ
Zend_Mail
導入
SMTP 経由での送信
SMTP 接続による複数のメールの送信
異なる転送手段の使用
HTML メール
ファイルの添付
受信者の追加
MIME バウンダリの制御
追加のヘッダ
文字セット
エンコーディング
SMTP 認証
セキュアな SMTP トランスポート
メールメッセージの読み込み
Zend_Measure
導入
計測値の作成
計測値の出力
計測値の操作
計測値の型
Zend_Memory
概要
メモリマネージャ
メモリオブジェクト
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Introduction
画面
Containers
Zend_OpenId
導入
Zend_OpenId_Consumer の基本
Zend_OpenId_Provider
Zend_Paginator
導入
使用法
設定
高度な使用法
Zend_Pdf
導入
PDF ドキュメントの作成および読み込み
PDF ドキュメントへの変更内容の保存
ページの操作
描画
ドキュメントの情報およびメタデータ
Zend_Pdf モジュールの使用例
Zend_ProgressBar
Zend_ProgressBar
Zend_Reflection
導入
Zend_Reflectionサンプル
Zend_Reflectionリファレンス
Zend_Registry
レジストリの使用法
Zend_Rest
導入
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
概要
インデックスの構築
インデックスの検索
クエリ言語
クエリ作成用の API
文字セット
拡張性
Java Lucene との相互運用
応用
ベストプラクティス
Zend_Server
導入
Zend_Server_Reflection
Zend_Service
導入
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Stroage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
導入
Zend_Service_StrikeIron
Zend_Service_StrikeIron: バンドルされているサービス
Zend_Service_StrikeIron: 応用編
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
導入
基本的な使用法
高度な使用法
グローバルセッションの管理
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDLアクセッサ
自動検出
Zend_Tag
Introduction
Zend_Tag_Cloud
Zend_Test
導入
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
導入
Zend_TimeSync の動作
Zend_Tool_Framework
Introduction
Using the CLI Tool
Architecture
Creating Providers to use with Zend_Tool_Framework
Shipped System Providers
Zend_Tool_Project
Zend_Tool_Project導入
Create A Project
Zend Tool Project Providers
Zend_Translate
導入
Zend_Translate のアダプタ
翻訳アダプタの使用法
以前のバージョンからの移行
Zend_Uri
Zend_Uri
Zend_Validate
導入
標準のバリデーションクラス群
バリデータチェイン
バリデータの書き方
検証メッセージ
Zend_Version
Zend Framework のバージョンの取得
Zend_View
導入
コントローラスクリプト
ビュースクリプト
ビューヘルパー
Zend_View_Abstract
以前のバージョンからの移行
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
導入
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework のシステム要件
導入
Zend Framework PHP 標準コーディング規約
概要
PHP ファイルの書式
命名規約
コーディングスタイル
Zend Framework Performance Guide
導入
クラスの読み込み
Zend_Dbパフォーマンス
国際化(i18n)とローカライズ(l10n)
ビューのレンダリング
著作権に関する情報