Hi guys, it's been a long while since I've been to these forums but I'm in a bit of a predicament at the moment trying to resolve an issue of who is responsible for what (between my Router & Dispatcher).

I have a working Router implemented which takes a series of Route patterns and matches them against a given URL. The first to match successfully will have my Router return a Command object full of all the goodies my Dispatcher needs (name of controller, action and any other parameters).

At the moment this Command object would be passed to the Dispatcher to initiate the controller and dispatch the action.

It is however right at this same point that I am a little stuck with how to handle things.

I would very much like to have the ability (as most frameworks do) to default back to a default Module, Controller & Action if the Route returned by my Router is not dispatchable as is.

Here is where the problem lies. What (between the Router & the Dispatcher) do you guys think should be responsible for injecting these defaults?

On one had I have a Router which in my eyes should simply match patterns to urls and hand control to something else when it's done. On the other hand, I don't want the Dispatcher to be playing around with what is (at this stage) considered a valid Route.

A big part of me want's this to be handled at the Router. I already have plans for another step in the bootstrap process to sit between the Router and Dispatcher but it (this other step) will definitely require knowledge of what is about to be dispatched. However allot of code that I have seen seems to have the Dispatcher attempt to load what the Router has given it, and if it can't the dispatcher itself starts injecting defaults until it can.

Any thoughts on the subject would be much appreciated. Thanks.

ps: I have the project hosted on Github if seeing code might make things clearer. I just didn't want to link it here as I haven't posted in a while and didn't want to give the impression I was spamming.

    5 days later

    Nobody has any input? It seems all the decent programmers have moved on to Ruby 🙁

      I'd say you should have the code for default fallback in the dispatcher since it's the dispatcher that knows if the route is undispatchable. If the router needs to be involved in what default fallback to use on undispatchable route, the router should provide this information to the dispatcher.

      This way you will have the default fallback code in one single place, instead of most likely being spread out in mulitple places in the router, which means that if you ever need to change or replace it, there is one single place to deal with. At the same time you have the option of additional control where needed, but while these default overrides may be spread out, you can also easily fund these places by using regexp to find where the extra function parameter is provided.

        Write a Reply...