3 ms·

How is this not just a slower .htaccess implementation with OOP boilerplate? The instructions even mention editing .htaccess, so it's not like this is necessari

How is this not just a slower .htaccess implementation with OOP boilerplate? The instructions even mention editing .htaccess, so it's not like this is necessarily intended for people who don't have control of it. RewriteRule ^foo/([0-9]+)/bar /foo/bar.php?x=$1 [L,NC,QSA] Done. These things come across as monkey-see-monkey-do. Other frameworks in other languages have routers, therefore they must also make sense in PHP.

jasonmoo 14y ago
There are benefits to keeping your routing in your app. Using different route sets based on environment variables, specifically migrating from one version of an api to another is not possible or easy with a purely htaccess router. But I agree that in some cases the fastest you can do is an htaccess route.
- benatkin 14y ago
  > There are benefits to keeping your routing in your app. Using different route sets based on environment variables, specifically migrating from one version of an api to another is not possible or easy with a purely htaccess router. I'm not excited to correct you, because the way it it doesn't quite hold true involves dragons, but I thought I would in case people doubt the power of apache configuration (nginx is much the same way). It is possible, with included modules like the one below. There is also the ability to use custom modules, which are programmatic in nature and have access to Apache at a low level. Since it wasn't specified whether a shared host is being used, I think it's within the scope of the discussion. http://httpd.apache.org/docs/2.2/env.html http://httpd.apache.org/docs/2.2/env.html
chc 14y ago
And then somebody tries to run your app in nginx. Tying your app to a particular server is a design choice. Some people like it, some people don't.
- laacz 14y ago
  If someone tries to run app on nginx or lighttpd, he (or she) already knows how to mimic .htaccess rules in their webserver of choice.
tomjakubowski 14y ago
Keeping routing in-app lets you 'reverse route' (generate a route for a resource) without violating DRY.
jakejake 14y ago
There's always the argument of abstraction vs simplicity. I appreciate both and I didn't used to like using routers. But I do use it these days for most of my work. Apps often don't have a physical URL that you could map to in .htaccess like /foo/bar.php. There's only index.php and the appropriate controller/method is executed based on the URL. Of course you could just map .htaccess to something like /index.php?method=foobar instead. But then you're still dealing with a router in your index.php, perhaps a simple switch statement or something. It wouldn't bother me to see this kind of setup but I think having a router is just a bit cleaner. You can also abstract retrieving values from the URL like /account/1234 (obtaining "1234") so that the router does all the parsing and the controller isn't aware of the URL implementation. Perhaps useful for altering URLs later without affecting the controller code. Keeping things separate also can make unit testing somewhat easier as you can substitute the router with a mock object and get your controller to respond to all the variations of user input.
- Ralith 14y ago
  > There's always the argument of abstraction vs simplicity. This is a false dichotomy. A good abstraction makes things simpler.
  - jakejake 14y ago
    You're talking about abstraction in general and I'm talking about a specific implementation.
mmcnickle 14y ago
Not really, most frameworks use a router to ensure the application has a single point of entry. Most PHP frameworks adopt a router too. A very common use case that requires a router that .htaccess wouldn't provide is if you want to have some middleware run before or after a request (for setting cache values for some resources and not others). There are other benefits too when it comes to testing as you can test (route) requests to views without having to make a call to the server. Edit: Removed unnecessary snarky comment.

jasonmoo 14y ago

There are benefits to keeping your routing in your app. Using different route sets based on environment variables, specifically migrating from one version of an api to another is not possible or easy with a purely htaccess router. But I agree that in some cases the fastest you can do is an htaccess route.

benatkin 14y ago
> There are benefits to keeping your routing in your app. Using different route sets based on environment variables, specifically migrating from one version of an api to another is not possible or easy with a purely htaccess router. I'm not excited to correct you, because the way it it doesn't quite hold true involves dragons, but I thought I would in case people doubt the power of apache configuration (nginx is much the same way). It is possible, with included modules like the one below. There is also the ability to use custom modules, which are programmatic in nature and have access to Apache at a low level. Since it wasn't specified whether a shared host is being used, I think it's within the scope of the discussion. http://httpd.apache.org/docs/2.2/env.html http://httpd.apache.org/docs/2.2/env.html

chc 14y ago

And then somebody tries to run your app in nginx. Tying your app to a particular server is a design choice. Some people like it, some people don't.

laacz 14y ago
If someone tries to run app on nginx or lighttpd, he (or she) already knows how to mimic .htaccess rules in their webserver of choice.

tomjakubowski 14y ago

Keeping routing in-app lets you 'reverse route' (generate a route for a resource) without violating DRY.

jakejake 14y ago

There's always the argument of abstraction vs simplicity. I appreciate both and I didn't used to like using routers. But I do use it these days for most of my work. Apps often don't have a physical URL that you could map to in .htaccess like /foo/bar.php. There's only index.php and the appropriate controller/method is executed based on the URL. Of course you could just map .htaccess to something like /index.php?method=foobar instead. But then you're still dealing with a router in your index.php, perhaps a simple switch statement or something. It wouldn't bother me to see this kind of setup but I think having a router is just a bit cleaner. You can also abstract retrieving values from the URL like /account/1234 (obtaining "1234") so that the router does all the parsing and the controller isn't aware of the URL implementation. Perhaps useful for altering URLs later without affecting the controller code. Keeping things separate also can make unit testing somewhat easier as you can substitute the router with a mock object and get your controller to respond to all the variations of user input.

Ralith 14y ago
> There's always the argument of abstraction vs simplicity. This is a false dichotomy. A good abstraction makes things simpler.
- jakejake 14y ago
  You're talking about abstraction in general and I'm talking about a specific implementation.

mmcnickle 14y ago

Not really, most frameworks use a router to ensure the application has a single point of entry. Most PHP frameworks adopt a router too. A very common use case that requires a router that .htaccess wouldn't provide is if you want to have some middleware run before or after a request (for setting cache values for some resources and not others). There are other benefits too when it comes to testing as you can test (route) requests to views without having to make a call to the server. Edit: Removed unnecessary snarky comment.