Front Controller design

[phpPunk]

[b]Edit:[/b] [i]I am already aware that FC are composed of thwo sub-systems of sorts (message handler/command dictionary, etc) I'm not looking for disscussion for clarity here, but rather the name router and whether it's justified or not???[/i]

Having read up on the Zend & Symphony front controllers and brushed up the pattern by reading various articles online...I have decided to implement my own based on Zend and Symphony.

I'm a stickler for names, proper naming is very important to me...and right now I am quite uncomfortable with Zend's term "router"

Why? Well if I understand it's purpose, it's actually more of a mapper as all it does is decompose a URL or GPC and "route" what Zend refers to as Dispatch tokens to the dispatcher which takes control from there. So really I would argue that it's actually mapping GPC variables to appropriate dispatch objects. Routing to me is more analogous to dispatching. Routing a message from one component to another...not so much tokenizing a URL and passing the tokens to a dispatcher..Saying that I can see why maybe Zend would call it a router, as they are looking at it one step after me. Mapping the GPC to a dispatch object (my perspective) routing the dispatch object to the dispatcher (next step - their perspective)...

It seems to me that routing or mapping process is actually a two part operation...hence my confusion or problem accepting their terminology...

Anyone else care to throw in a perspective?

Cheers :)

[Jenk]

Yes, it is a two (or more) part operation, and it always will be. The first part is deciphering the information. The default method with the ZF preview, is the use of a request uri with '/var/val/var/val' routes, and static members of said routes.

So the first stage is to 'decode' that information and decide which controller needs loading.

The second is load the controller, and to dispatch the additional information to the controller.

[448191]

Even at ZF this question was raised. It is argued that for flexibilty dispatching and decoding the uri "route" should remain separate.

I can understand your problem with the name "Router" though, as the class itself doesn't "route" anything.

For your own framework name as you will of course (RouteDecoder?  :P), but I recommend you keep previously mentioned processes separated.

[phpPunk]

[quote author=Jenk link=topic=116959.msg476995#msg476995 date=1164984465]
Yes, it is a [b]two (or more) part operation[/b], and it always will be. The first part is deciphering the information. The default method with the ZF preview, is the use of a request uri with '/var/val/var/val' routes, and static members of said routes.

So the first stage is to 'decode' that information and decide which controller needs loading.

The second is load the controller, and to dispatch the additional information to the controller.
[/quote]

Care to offer details into the "more" abstraction?

I believe (particularly in PHP) it's possible to further decompose the Fowler front controller definition (which is a two part system if I understand it correctly).

I'm interested in hearing how you feel it can be further broken down/abstracted?

[448191]

Dito here.  ;D

[Jenk]

Well, as an example.. I've already mentioned 3 steps.
1. establish requested route
2. Instantiate sub/page-controller.
3. dispatch request info to controller.

[448191]

I believe you can make as many or little steps as you like. It just depends on the size of your steps. It's not really important, now is it?

I agree that the name "router" can be confusing, as it implies that it does what in actuallity the dispatcher is responsible for. However someone DID name this pattern the Router pattern, so it's not surprising Zend names it so. Also, if you move away from thinking separately about strings and objects, routing as in the dictionary defintion does apply.

[quote=perldesignpatterns.com::Router pattern]Multi input or multi output [b]information conduit[/b]. One object takes data from multiple sources, and passes it to a single object, or else information from a single source is sent to multiple objects. Combine two to take input from many sources and send output to many targets.[/quote]

ZF only uses a single dispatcher per route instruction (page controllers can use $_nextAction which will instruct the dispatcher to continue the dispatching loop), but I suspect that might change as it would be more flexible to have the router spawn mutliple dispatchers. However, the current way of route formatting doesn't allow for multiple page controllers, so multiple dispatchers wouldn't be useful at all, at this time.