4

我正在将一个遗留应用程序移植到 Symfony2 并且我正在苦苦挣扎，因为路由不包含查询字符串参数。一些简单的示例：假设您有一个书籍搜索页面，您可以在其中根据条件过滤结果：

http://www.bookstore.com/books?author=Stephen+King&maxPrice=20

在这种情况下，查询字符串参数的好处是您可以拥有任意数量的过滤器，将您想要的过滤器用于任何给定的请求，并且不会用您不使用的过滤器将 URL 塞满。

假设我们使用 Symfony2 路由组件重写了上述查询的路由。它可能看起来像这样：

http://www.mybookstore.com/book/any_title/stephen%20king/any_release_date/max_price_20/any_min_price/any_format/any_category

即使不考虑不干净的 URL 有多长，我仍然认为它不那么直观，因为该路由的每个“段”不是键值对，而只是一个值（例如author=Stephen+King> /stephen%20king/）。

您当然可以通过将 Request 对象传递到操作方法（例如indexAction(Request $request) {）来访问控制器中的查询字符串参数，但随后验证它们并将它们传递到应用程序的其他部分变得很麻烦（即我现在发现自己的地方）。如果您使用 Knp Menu Bundle 构建侧边栏，并且希望.current根据查询字符串参数将部件标记为？没有任何功能，只有与 Symfony2 路由集成的功能。

以及如何验证您的查询字符串参数是否可以接受？我目前正在考虑像表单一样验证它们，然后将它们传递到数据库中以生成查询。也许这就是 Symfony2 团队设想的处理方式？如果是这样，我真的很想知道为什么。感觉就像我在与应用程序作斗争。

4

2 回答 2

2

我最终在 Symfony Live San Francisco 2012 上向 Fabien 提出了这个问题。在同一个会议上关于这个问题还有另一个演讲，我将在这里与你分享幻灯片：

http://www.slideshare.net/Wombert/phpjp-urls-rest#btnNext

基本上在幻灯片中，您可以看到作者同意我的观点，即查询字符串参数应该用于过滤。它们不应该用于确定内容源。因此，路由应指向产品（或其他），然后应在控制器中使用查询字符串参数来应用过滤该内容源所需的任何逻辑（根据 Fabien）。

我最终在我的应用程序中创建了一个实体，我将所有查询字符串参数绑定到然后进行操作，这与处理表单的方式非常相似。事实上，当你考虑它时，它基本上是一样的。

于 2012-11-26T20:13:33.693 回答
0

就像在 Symfony1 中一样，查询字符串独立于路由参数。

如果您将路径定义为@Route("/page/{id}", name="single_page")，则可以在视图中创建一个路径，如下所示：

{{ path('single_page', { id: 3, foo: "bar" }) }}

生成的 URL 将是/page/3?foo=bar.

于 2012-09-20T18:56:13.973 回答