Fat Free Framework 路由无法区分参数和 URI
Fat Free Framework routing cannot not differentiate parameters from URI
我正在尝试为所有类别、子类别和单个页面创建正确的路由。
我的问题是我的子目录路由和我的单页路由非常相似：
路线
GET /@category_slug = CategoryController->CategorySlug
GET /@category_slug/@subcategory_slug = CategoryController->SubcategorySlug
GET /@category_slug/@template_slug = SingleProductController->SinglePageSlug
类别控制器处理它需要处理的与类别和子类别相关的所有内容，但显然不会处理与单个页面相关的任何内容。我的意思是路由不会区分参数和URI，也不会识别它是Subcategory还是Single page。
这是一个示例 URI
example.com/MainCategory/Subcategory
example.com/MainCategory1/Subcategory1
example.com/MainCategory/SinglePage1
example.com/MainCategory/SsinglePage2
知道如何解决这个问题吗？
提前致谢
框架无法区分这两条路线的原因和人类是一样的。您怎么知道 /foo/bar 是子类别还是子页面？
所以你必须在你的URL结构中明确区分。这取决于你的想象力。这里有几个例子：
ex1:
/foo/foo/bar/foo/bar/page/baz
ex2:
/cat/foo/cat/foo/bar/page/baz
ex3:
/foo/foo/c/bar/foo/p/baz
ex4:
/foo/foo/bar/foo/baz.html << 这里的后缀有助于区分子类别和文章
ex5:
/foo/foo/bar/foo/bar/baz << 这里我们保留子类别级别
还有一个解决方案，就像您 自己一样，保持模棱两可的 URL 结构并让控制器猜测它是否应该显示子类别或单个页面。
GET /@category_slug/@slug = CategoryController->GuessSubcategoryOrSinglePage
但我不建议这样做，原因如下：
- 维护：代码可读性差
- 性能：每个页面显示一个额外的无用 SQL 调用
- SEO：搜索引擎试图从目录结构中猜测很多东西。在这里他们会失败，就像框架或人类会做的那样。
NB1：我个人偏爱示例 #2，因为为每个页面提供自己的 URL 可以让一个页面属于多个类别，而无需处理 duplicate content 问题。当您必须构建页面时，它也会让您的生活更轻松 URL（无需构建类别层次结构，无论您在代码中的哪个位置）。
NB2：不要过分关注制作 "pretty urls"，因为大多数最终用户从不关心它们。
我正在尝试为所有类别、子类别和单个页面创建正确的路由。
我的问题是我的子目录路由和我的单页路由非常相似：
路线
GET /@category_slug = CategoryController->CategorySlug
GET /@category_slug/@subcategory_slug = CategoryController->SubcategorySlug
GET /@category_slug/@template_slug = SingleProductController->SinglePageSlug
类别控制器处理它需要处理的与类别和子类别相关的所有内容，但显然不会处理与单个页面相关的任何内容。我的意思是路由不会区分参数和URI，也不会识别它是Subcategory还是Single page。
这是一个示例 URI
example.com/MainCategory/Subcategory
example.com/MainCategory1/Subcategory1
example.com/MainCategory/SinglePage1
example.com/MainCategory/SsinglePage2
知道如何解决这个问题吗？
提前致谢
框架无法区分这两条路线的原因和人类是一样的。您怎么知道 /foo/bar 是子类别还是子页面？
所以你必须在你的URL结构中明确区分。这取决于你的想象力。这里有几个例子：
ex1:
/foo/foo/bar/foo/bar/page/baz
ex2:
/cat/foo/cat/foo/bar/page/baz
ex3:
/foo/foo/c/bar/foo/p/baz
ex4:
/foo/foo/bar/foo/baz.html<< 这里的后缀有助于区分子类别和文章
ex5:
/foo/foo/bar/foo/bar/baz<< 这里我们保留子类别级别
还有一个解决方案，就像您
GET /@category_slug/@slug = CategoryController->GuessSubcategoryOrSinglePage
但我不建议这样做，原因如下：
- 维护：代码可读性差
- 性能：每个页面显示一个额外的无用 SQL 调用
- SEO：搜索引擎试图从目录结构中猜测很多东西。在这里他们会失败，就像框架或人类会做的那样。
NB1：我个人偏爱示例 #2，因为为每个页面提供自己的 URL 可以让一个页面属于多个类别，而无需处理 duplicate content 问题。当您必须构建页面时，它也会让您的生活更轻松 URL（无需构建类别层次结构，无论您在代码中的哪个位置）。
NB2：不要过分关注制作 "pretty urls"，因为大多数最终用户从不关心它们。