2

Play 1.x は でキャッチオール ルートを提供しましたconf/route:

# Catch all
*       /{controller}/{action}                  {controller}.{action}

しかし、Play 2.x ではこの機能が削除されたようです。

4

2 に答える 2

3

一般的に、この変更はtype-safe2.0 のアイデア全体の方向への一歩であり、間違っているとは思いません。

ルーティングを使用するフレームワークでtype-safeは、Play 2 のようにリンクはロジックの重要な部分であるため、「不明な」宛先を使用するとエラーが発生しやすくなり、同時にセキュリティが低下するため、これは適切ではありません。さらに、1.2 new routervalidates parameters types とは対照的に、アプリケーションの品質をさらに向上させますが、それぞれに 1 行追加する必要がありますaction。

最後に、クラスにカスタム 'dispatcher' メソッドを追加し、マルチセグメント パスを 'キャッチ' する可能性が常にありますasterisk rule(単一のパラメーターはコロンで識別されます)。

GET   /multi/*path    controllers.Application.mySubRouter(path)

これにより、リンク全体がディスパッチャ アクションの後に渡さhttp://domain.tld/multi/れ、ディスパッチャ アクションに送信されるStringため、これを使用してセグメントをスラッシュで分割し、最初の 2 つの要素をコントローラおよびリダイレクト先のアクション名として使用できます。

http://domain.tld/multi/MyController/myAction/p1/p2

ただし、そのような場合は、ディスパッチャに許可された組み合わせの追加の検証を組み込むことをお勧めします (おそらくカスタム DB ルール セットまたは正規表現などによって)。それ以外の場合は、私の議論のエントリ ポイントに戻ります。error prone+low security

于 2012-07-19T08:23:58.490 に答える