4

私は最初のZendFrameworkアプリケーションを構築しており、URLからユーザーパラメーターを取得するための最良の方法を見つけたいと思っています。

index、、およびアクションメソッドaddを持つコントローラーがいくつかあります。アクションはパラメーターをとることができ、アクションはパラメーターをとることができます。editdeleteindexpageeditdeleteid

Examples
    http://example.com/somecontroller/index/page/1
    http://example.com/someController/edit/id/1
    http://example.com/otherController/delete/id/1

これまで、アクションメソッドでこれらのパラメータを次のようにフェッチしていました。

class somecontroller extends Zend_Controller_Action
{
    public function indexAction()
    {
        $page = $this->getRequest->getParam('page');
    }
}

ただし、同僚から、Zend_Controller_Router_Rewriteを使用したより洗練されたソリューションについて次のように言われました。

$router = Zend_Controller_Front::getInstance()->getRouter();

$route = new Zend_Controller_Router_Route(
                        'somecontroller/index/:page',
                        array(
                            'controller' => 'somecontroller',
                            'action'    => 'index'
                        ),
                        array(
                            'page' => '\d+'
                        )
);

$router->addRoute($route);

これは、すべてのコントローラーに対して、少なくとも3つのルートを追加する必要があることを意味します。

  • 1つは:pageパラメータを使用した「インデックス」アクション用です
  • 1つは:idパラメーターを使用した「編集」アクション用です
  • 1つは:idパラメーターを使用した「削除」アクション用です

例として、以下のコードを参照してください。これらは、1つのコントローラーの3つの基本的なアクション方法のみのルートであり、10個以上のコントローラーがあることを想像してください...これが最善の解決策であるとは想像できません。私が見る唯一の利点は、パラメータキーに名前が付けられているため、URLから省略できることです(somecontroller/index/page/1になりますsomecontroller/index/1

// Route for somecontroller::indexAction()
$route = new Zend_Controller_Router_Route(
                        'somecontroller/index/:page',
                        array(
                            'controller' => 'somecontroller',
                            'action'     => 'index'
                        ),
                        array(
                            'page' => '\d+'
                        )
);

$router->addRoute($route);

// Route for somecontroller::editAction()
$route = new Zend_Controller_Router_Route(
                        'somecontroller/edit/:id',
                        array(
                            'controller' => 'somecontroller',
                            'action'     => 'edit'
                        ),
                        array(
                            'id' => '\d+'
                        )

$router->addRoute($route);

// Route for somecontroller::deleteAction()
$route = new Zend_Controller_Router_Route(
                        'somecontroller/delete/:id',
                        array(
                            'controller' => 'somecontroller',
                            'action'     => 'delete'
                        ),
                        array(
                            'id' => '\d+'
                        )

$router->addRoute($route);
4

3 に答える 3

2

私はそれをこのように見る傾向があります:

  1. 処理要件を決定します。

    それぞれの「行動」には何が必要ですか?編集アクションと削除アクションには、おそらく:idパラメーターが必要です。追加アクションとリストアクションはおそらくそうではありません。次に、これらのコントローラー/アクションはパラメーターを使用して処理を実行します。

    注:訪問者をそこに誘導するURLを参照せずに、これらのコントローラー/アクションを記述できます。アクションは、パラメータが配信されることを単に期待しています。

  2. 必要なURLを決定(!)します。

    一般に、URLの一部はほぼ正常に機能します(たとえば、IndexController(またはStaticController)にアクションを配置し、URLにプレフィックスを含める必要があることに憤慨して(/:module/):controller/:actionいるようなトップレベルの比較的静的なページを除く) 。/about/index

    したがって、投稿を処理するには、次のようなURLが必要になる場合があります。

    • /post-おそらくいくつかのページングを使用して、すべての投稿を一覧表示します
    • /post/:id-特定の投稿を表示する
    • /post/:id/edit-特定の投稿を編集する
    • /post/:id/delete-特定の投稿を削除します
    • /post/add-投稿を追加します

    または、次のようにすることもできます。

    • /post/list-おそらくいくつかのページングを使用して、すべての投稿を一覧表示します
    • /post/display/:id-特定の投稿を表示する
    • /post/edit/:id-特定の投稿を編集する
    • /post/delete/:id-特定の投稿を削除します
    • /post/add-投稿を追加します

    または他のURLスキーム。重要なのは、公開するURLを決定することです。

  3. ルートを作成...

    ...これらのURLをコントローラー/アクションにマップします。[そして、それらをレンダリングするときは常にurl()、route-nameでview-helperを使用するようにしてください。これにより、ルーティングを変更しても、アクションまたはビューのダウンストリームコードを変更する必要がなくなります。

この方法でさらに多くのルートを作成することになりますか?ええ、私はそうしていることがわかります。しかし、私にとっての利点は、URLを決定できることです。私はZendのデフォルトに固執していません。

しかし、ほとんどのものと同様に、YMMV。

于 2012-11-15T09:19:19.620 に答える
1

それはすべてあなたの正確な要件に依存します。単に1つまたは2つのパラメータを渡したい場合は、最初の方法が最も簡単です。すべてのアクションのルートを定義することは実用的ではありません。ルートを定義するいくつかのシナリオは次のとおりです。

  1. 長いURL-特定のアクションのパラメータリストが非常に長い場合は、リクエストからキーを省略してURLを短くできるようにルートを定義することをお勧めします。
  2. ファンシーURL-ZendFrameworkの通常のコントローラー/アクションURLパターンから逸脱し、アプリケーションに別のURLパターンを定義する場合(たとえば、「。html」で終わる)
  3. スラッグ/SEOフレンドリーなURL

ブログの例をとると、URLがSEOに適したものになるように、ブログ投稿のURLのルートを定義することができます。同時に、編集/削除/コメントの投稿などのURLを保持してZFのデフォルトのままにし、$ this-> getRequest-> getParam()を使用してそのコンテキストのリクエストパラメーターにアクセスすることもできます。

要約すると、エレガントなソリューションは、ルートとデフォルトのURLパターンの組み合わせになります。

于 2012-11-15T07:48:28.297 に答える
0

以前の回答で、@janenz00はルートを使用する理由の1つとして「長いURL」について言及しました。

長いURL-特定のアクションのパラメータリストが非常に長い場合は、リクエストからキーを省略してURLを短くできるようにルートを定義することをお勧めします。

各従業員の追加データ(年齢、部門など)を含む従業員のテーブルを表示するアクションを持つemployeeコントローラーがあるとします。アクションは次のパラメーターを取ることができますindexindex

  • パラメータpage(必須)
  • 並べ替えに1つの列名を使用するsortbyパラメーター(オプション)(例:年齢)
  • dept部門の名前を取り、その部門で働いている従業員のみを表示するパラメーター(オプション)

以下のルートを追加します。このルートを使用する場合、最初deptにパラメーターを指定せずにパラメーターを指定することはできないことに注意してsortbyください。

$route = new Zend_Controller_Router_Route(
                    'employee/index/:page/:sortby/:dept',
                    array(
                        'controller' => 'employee',
                        'action'    => 'index')
);

代わりに、アクションメソッドでこれらのパラメーターをフェッチすると、この問題を回避できます(パラメーターキーがURLで指定されているため)。

http://example.com/employee/index/page/1/dept/staff

私はそれを間違った方法で見ているかもしれません(またはルーティングの可能性を完全に理解していないかもしれません)が、私にとってルートを使用する唯一の理由は次のとおりです。

  • /module/controller/actionURLが従来のパターンに準拠していない場合
  • URLをよりSEOに適したものにしたい場合

ルートを使用する唯一の理由が名前付きパラメーターを使用することである場合、次の2つの理由から、アクションメソッドでこれらのパラメーターをフェッチする方がよいと思います。

  • ルートの数を最小限に抑えることで、ルーターが費やす時間とリソースの量を減らすことができます
  • URLにパラメータキーを渡すと、オプションのパラメータを使用してより複雑なURLを利用できます。

このトピックに関する考えやアドバイスは大歓迎です!

于 2012-11-15T13:48:26.457 に答える