phpPunk Posted December 1, 2006 Share Posted December 1, 2006 [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 :) Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/ Share on other sites More sharing options...
Jenk Posted December 1, 2006 Share Posted December 1, 2006 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. Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-133427 Share on other sites More sharing options...
448191 Posted December 2, 2006 Share Posted December 2, 2006 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. Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-133890 Share on other sites More sharing options...
phpPunk Posted December 2, 2006 Author Share Posted December 2, 2006 [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? Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-133934 Share on other sites More sharing options...
448191 Posted December 2, 2006 Share Posted December 2, 2006 Dito here. ;D Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-134048 Share on other sites More sharing options...
Jenk Posted December 2, 2006 Share Posted December 2, 2006 Well, as an example.. I've already mentioned 3 steps. 1. establish requested route2. Instantiate sub/page-controller.3. dispatch request info to controller. Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-134106 Share on other sites More sharing options...
448191 Posted December 3, 2006 Share Posted December 3, 2006 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. Quote Link to comment https://forums.phpfreaks.com/topic/29083-front-controller-design/#findComment-134271 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.