Page 1 of 1
request mapping
Posted: Tue Dec 25, 2007 12:11 am
by s.dot
I really am sorry for posting all of these questions.

I googled, of course, and I find about a million different examples, but nothing that explains what's going on. Perhaps someone could show me a good tutorial or article?
I've got a bunch of basic classes made. And I think I'm at the point now where I need a request mapping system (if that's even what it's called).
I want a single point of entry.. ie (index.php?page=xxx).. I'll chop this later using a rewrite rule
My personal thinking goes something like this:
Code: Select all
require 'path/to/request.php';
$request = new request();
if ($request->isValidRequest($_GET['page']))
{
$request->dispatch($_GET['page'];
}
Something like a front controller? Of course the dispatch() method would load the controller for that specific page, which when then load in variables from my registry (containing config and database objects).
Is this how it's usually done? After I get the front controller made, do I need a sub controller for each page?
Posted: Tue Dec 25, 2007 6:33 am
by Maugrim_The_Reaper
I'd push any request error detection further down the line - enough that when an error is evident you can re-dispatch to a controller handling 404s.
Mapping requests to a controller is a job for a Router. It takes a URI, parses it, and extracts the information needed to dispatch through a Controller/Action or Command. For example
http://example.com/signup/index could route to the Index method of the Signup controller. Or as is common, you can just omit the /index and shorten to
http://example/signup (the index would be a default value - otherwise your home page would be
http://example.com/index/index)
This really starts linking to the concept of REST eventually. Consider the url to a User page:
http://example.com/user/account/id/scottayy. To a Router the id/scottayy part is interpreted as a kind of GET parameter (it's not GET, but the effect is similar) where a parameter pair of id=scottayy is created. That's another reason why a Request object of some description is handy - POST, GET, COOKIE are not the only feasible source of parameters in a RESTful application.
Using a GET param:
http://example.com?page=user/account/id/scottayy.
One you have a URI format of a similar type the method of Request mapping for Routing will become more readily apparent. I'd suggest seeing what arborint & co. framework does. Other frameworks have Routers also.
Re: request mapping
Posted: Sat Jan 12, 2008 11:52 pm
by jimthunderbird
I agree with Maugrim_The_Reaper, if you wish to take a look at an example how router works, download codeigniter (
http://www.codeigniter.com/) and take a look.
Re: request mapping
Posted: Sun Jan 13, 2008 8:20 am
by Kieran Huggins
I'd cut mod_rewrite out altogether if you're going to have a request mapper. Instead, parse the query_string as is. Some routers make heavy use of regex patterns (which can be a good thing) and others parse their own formats.
Consider:
Code: Select all
// automatically parses out the variables and passes them to the correct controller/action
Route::map('/#controller#/#action#/#id#');
// custom route for searches
Route::map('/search/#terms#')->to(array('controller'=>'search','action'=>'index'));
That way you can build a URI generator that builds links for a set of variables:
Code: Select all
// builds a route to show user 15
Route::uri_for(array('controller'=>'user','action'=>'show','id'=>'15'));
now that would look through the defined routes for the first one that includes all the variables you've passed, builds a matching URI, then tests the URI by parsing the route to see if you get the same info out that you put in.
Re: request mapping
Posted: Sun Jan 13, 2008 8:53 am
by superdezign
You could make a simple router that only takes a controller and an action (as I have), and then as you get deeper in controllers, just forward the requests to the next controller in the hierarchy.
The router takes the $_SERVER['REQUEST_URI'] variable (which I always strip the query string off of in order to deal with $_GET variables within the controllers themselves), and then a route in the form of "/${controller}/${action}/" (since I like using ${...} for templating) as long as there is some sort of character defining the boundaries for tokenization. Then, the controllers take the 'controller' and 'action' portion and create a controller class and an action method using that data.
The weakness of this, however, is that if I were given a URL that was '/controller/action/uselessData/,' My router wouldn't recognize the uselessData portion at all since I forward requests on my own. I'd remove the request forwarding, but sometimes I want one controller to have control of a very deep portion of the request.
Also, Chris made a router called Roo. I never used it because I prefer to write things on my own to see how it's done (aside from Swiftmailer

), but it looked promising.