Toro - a php micro-router with great examples | Hacker News Reader

Toro - a php micro-router with great examples

github.com

34 pointsjasonmoo54 comments

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.

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.

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

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.

> There's always the argument of abstraction vs simplicity.

This is a false dichotomy. A good abstraction makes things simpler.

You're talking about abstraction in general and I'm talking about a specific implementation.

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.

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.

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.

> 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

Well done! This has a really clean interface, I wish I'd come across it when looking for a simple router a few weeks ago. A lot of the other ones lean heavily towards a style associated with their related framework, or are too esoteric/basic.

There are a few things I would have to add before I would use it however, and I hope they make it in some day:

1) You should add a whitelist for the HTTP request method names, i.e only allow calls to get(), post(), not some_suspicious_call_from_bad_user(). People will often put non HTTP methods in their views (view as in django sense) and you don't want them to be able to be called by a malicious user.

2) You should make it easy for the developer to configure their own xhr headers.

3) Nitpick: You should probably use 405 (Method Not Allowed) instead of 404 for when a method handler isn't found.

Maybe I'll use it in this project, in which case you may have a few pull requests headed your way!

Wow fantastic code review! I'm a minor contributor on this project and those changes sound great.

Related: A similar project (a simple php router) called Klein exists (https://github.com/chriso/klein.php) which is really great. Does anyone have experience with both and can explain which is better?

I love Klein, but this looks WAY easier to work with and much more specific. Klein includes a bunch of stuff for request and response handling, output buffers and views and stuff. Toro appears to completely leave all that to the implementer, which is very nice if you've already got code to handle those things.

Thanks for posting this. I hadn't seen Klein before and the simplicity and minimalism of the API really appeals to me. I'm using Slim so far and it has some serious drawbacks (no namespaced routes, no response()->write(json), overly complicated view system)

Reminds me of many things; as usual, the weakest part of this PHP router is the .htaccess file.

I don't think you can do this kind of url routing in php without modifying the .htaccess file.

And so it's permanently married to Apache. Too bad.. is there anything like this that'll run on nginx/lighttpd?

All of these routers work under Nginx or Lighttpd, they just need a different config file. Here's one that is often used under Nginx:

    location {
        root   /usr/share/nginx/html;
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$request_uri;
    }

I think it's pretty trivial to change the htaccess rewrite rule into an nginx/lighttpd rule.

It's just a matter of altering your nginx configuration to rewrite requests.

https://gist.github.com/3441804

In lighttpd, enable mod rewrite and:

url.rewrite-once = ( "^/(.*)$" => "index.php/$1" )

I've used Toro for about six months. It's excellent.

Yeah me too. It's been a great tool for me as well.

Simple, elegant solution to a typical problem where everybody else ends up building a broken wheel.

Agreed. This may have replaced Sinatra for my go-to for building quickie Rest APIs

have you tried SlimPHP? I've been using it for APIs lately and its been great. Very easy to get up and going very quickly.

Looks similar to Fat Free Framework for PHP, which I've been using for a few months. http://bcosca.github.com/fatfree/

Like everybody else, I wrote my own router which somehow began to grow and became a so-called microframework: http://azuki.desfrenes.com/

This is probably what I would use for PHP, but obviously other languages have better solutions like ruby/sinatra, python/flask etc.

The toro mascot on the main site is pretty cool. http://toroweb.org/

It's an interesting approach. I use SlimPHP, which approaches the RESTful API problem as a DSL, much like Sinatra. Slim has a few nice features, and my new preferred PHP stack is Slim Framework + Zend Framework as a library.

How can I bypass images or specific files using ToroPhp? I usually add this lines at my .htaccess:

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d

You do just that. When setting your .htaccess to route all URLs through Toro, use a snippet like:

RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php

I used Moor for several projects and works like charms and it's very easy to use ( https://github.com/jeffturcotte/moor )

Similar to GluePHP: http://gluephp.com/documentation.html

This illustrates exactly why PHP projects often become such an unmaintainable mess and security hole. This looks like an example collection of PHP worst practices.

I mean, what could possibly go wrong with untestable code and unfiltered input...?

Not sure how adding some input filtering and tests would make this an unmaintainable mess..?

The code is actually pretty tight and is optimized for empowering a developer rather than inflating the bumpers of your bowling lane.

Untestable code? How is it untestable?

Unfiltered input? You realise that this is a router, right? The only 'input' is the URL path.

I really wish you could be more specific about these 'worst practices' that make this 91-line library an 'unmaintainable mess and security hole'.

That's not the problem this solves. This is 91 lines of code that solve one problem, routing, and that problem only. You filter input right afterwards.

And how is this untestable, exactly? It's really easy to fake http requests in php-cli from a unit test, for instance. And is there any other way you'd want to test a router than by faking php requests? I somewhat wonder whether the fact that this happens to be PHP biased your judgment.

If anything I find that a router makes your code easier to test. If you're 100% consistent about using the router to obtain user input, then your code is easy to unit test with a mock router. Routers themselves can be easy to test as well.

It's a clean separation of concerns - the router is the only thing that knows about the URL implementation. The rest of the code relies on the router to do that. That's a good practice to me.

What would you would consider "best practice" in place of a router?

i wish zend framework's router was this easy

Looks clean. Way to ship!

i love it

Is this a parody of how not to do things? I was prepared to take it on face value of being rather misguided, but thinking about it... It's a glorified mess of goto statements and objects being misused.

I confess that I stopped digging further after I saw files being included in methods, absolutely one of the biggest sins in PHP:

https://github.com/anandkunal/ToroPHP/blob/master/examples/b...

Not that I've looked at it in much depth, but those just look like simplistic examples to show how the routing works. If it's just a router, then how you render views is beyond the scope of the library, and cutting corners in examples for the sake of expediency doesn't seem so bad.

I'm fine with the idea of a router simply being a router; I really take exception to yet more PHP examples illustrating bad coding habits being on the web though.

I can agree with that. Even just changing it from

include("views/articles.php");

return view ('articles');

would be better...

Those are examples, with example page handlers.

The actual library code is just the 91 line file in the root directory. I don't understand why people are being so negative about 91 lines of code. It's very simple and most of it is quite well written.

How is this project 'misguided', just from face value?

Those are examples, with example page handlers.

Right - and examples are meant to illustrate how to best use a library.

And they do show the best way to use the router. Rendering content is not related to the library at all.

How you write your handlers and display your views is completely up to you. Why should a simple router dictate how you write the rest of your code?

I agree that it could negatively influence code that more novice programmers might write with it. They should replace the code inside the page handlers with a comment indicating that the user should render output there.

Most frameworks hide including views by way of extract() and output buffering. There's no real benefit to doing that on a small app. And no benefit on an api.

Most frameworks hide including views by way of extract() and output buffering. There's no real benefit to doing that on a small app. And no benefit on an api.

There's always a benefit to not copying and pasting code, which is what writing an include in each of your handlers boils down to.

Could you offer some form of explanation as to why you find conditional includes so odious?

Could you offer some form of explanation as to why you find conditional includes so odious?

It boils down to sloppy thinking; your objects should be well defined enough that you're not having to include extra pieces of code in the middle of execution.

You could argue code reuse - but why isn't that code either part of the object in the first place, or an object in its own right?

If you know some examples of elegant code written with includes scattered throughout it, conditionally or otherwise, I'd love to see it.

I will make exceptions for some parts of page rendering; it can sometimes be a good idea to put page elements into their own files and pull together when necessary. But for including code? No. Just no.

Edit: I took exception in this case, as it's non-obvious what happens once the view file has been included, not to mention the lack of a base example handler class implies and encourages people to write code like this.

Reply on news.ycombinator.com