큰 기존 링크 카탈로그로 기존 웹 사이트를 다시 작성해야했습니다. 논증의 여지없이, 우리가 링크 카탈로그를 바꿀만한 일을 할 수 없다고 가정 해 봅시다. 여기에 우리가 작업중인 링크 구조의 몇 가지 예를 다음과 같습니다맞춤 리튬 라우팅 시나리오
아이템 페이지는 다음과 같습니다
www.domain.com/widgets/some-totally-awesome-large-purple-widget
카테고리 서브 페이지 페이지는 다음과 같습니다
www.domain.com/widgets/purple-widgets
카테고리 상위 페이지 페이지는 :
www.domain.com/widgets/
사용자 정의 페이지가 될 수있다 :
www.domain.com/some-random-page
다양한 페이지 유형에 대한 개별 라우터를 쓰기에는 너무 많다.
Router::connect('/{:pageroot}/{:pagekey}', 'Pages::index');
차례로, 페이지 :: 인덱스 방법은 "키"우리의 데이터베이스에있는 항목을 찾습니다
라우터를 사용하여 :: 내가 좋아하는 뭔가를 사용하여 제 1 및 제 2 시나리오에 대한 계정을 쉽게 할 수 있습니다 연결 '/ widgets/purple-widgets'중 하나입니다.
그러나 프레임 워크는 기본적으로 세 번째와 네 번째와 같은 페이지의 경우 '/ {: controller}/{: action}/{: args}'경로를 사용합니다. 이것이 프레임 워크의 올바른 동작이라는 것을 알고 있습니다. 또한 모범 사례는이 동작과 일치하도록 사이트를 작성해야한다고 명시합니다. 하지만, 여기서는 옵션이 아닙니다.
내가 필요로하는 라우터는 세 번째와 네 번째 예제가 첫 번째와 동일한 기능을하도록 허용합니다. 모든 예제는 Pages :: index 컨트롤러로 전송되어야하며,이 컨트롤러는 URL 경로를 키로 사용하여 데이터베이스를 쿼리합니다.
사용자 지정 Route()를 지정하는 것이 좋지만 사용할 수는 없습니다. 나는 나중에 그 장난감을 가지고 놀 것이다. 약간의 조정을 한 첫 번째 해결책은 훌륭하게 작동했습니다. Router :: connect()에 대한 $ params 배열을 지정할 수 있다는 사실을 잊어 버렸습니다. –
@EricC 중요한 'keys' 매개 변수가 누락되었습니다. 정규 표현식과 컨트롤러가받는'Request :: $ params '사이의 일치가 발생합니다. – greut