Custom router (custom construUrl) – dealing with parameters

Notice: This thread is very old.
lutor
Member | 27
+
0
-

Hi,
we have custom router for routing in eshop.
We have routes like:

/category1-slug/subcategory1-slug/product1-slug
/category2-slug/product2-slug
/category3-rendered-as-product-list-slug
/category4-rendered-as-category-detail-slug

⇒ one route for product detail (with category-path in tree), basically two routes for category, which is (based on category options) routed to detail or as list of products.
So in our eshop presenter, we have three actions – detail (of product), category (detail of category), list (of products in specified category).

Our motivation was to create custom router, that will match/generate URLs based on given product/category ID, set presenter's action based on category's properties, will check and generate product-category path in tree, so it will never happen that presenter's action will be called even if product/category does not exist. If wrong URL is given to match or wrong product/category ID is given to construct URL from, router simply does not match or declines to generate route (so “No route for …” notice is generated).

So we made our implementation extending Route, overriding constructUrl method (which probably was not the best idea, but i will get to it) and match method.
It works as expected, but problem is, that if we have for example a form component in presenter under this router and after form is submitted, we set some persistent parameters and redirect back to ‘this’. So far so good. Problem is, that our router keeps all the parameters from previous request (do, submitted fields etc.), so submit-signal handler is called again and again in infinite redirect loop.

Matching route is not problem, problem is constructing URL, especially after redirects. The main problem is probably, that in our router we have rewritten constructUrl(), so it now uses clone of refUrl (second argument of constructUrl()) to construct target URL. It all without calling parent method. So none of the magic that happens inside Route::constructUrl…

My question is:
What is the recommended way to have router like described in motivation – dealing with tree paths, actions etc., maintaining Route's magic to construct URL but in our way? Use standard router and use IN/OUT filters? Any other way?

Thanks.