23 comments

[ 4.5 ms ] story [ 65.5 ms ] thread
This is pretty early but nifty, and might help us in our ongoing efforts to move away from our Ruby prototypes. Needs helpers and halting to be properly useful, but will definitely keep an eye on it.
Thanks! I'll get to helpers and halting as soon as I can, and email you when they're done.

Update: Done.

Looks promising! I've actually been developing my own Sinatra clone in PHP5. I've called it "Slim". It has RESTful GET, POST, PUT, DELETE routing. It has before and after callbacks. It has Page Not Found handling, halting, helpers to set custom response codes, and easy-to-extend templating (use Smarty, Twig, or whatever you want). See more at:

Documentation: http://slim.joshlockhart.com/

GitHub (with Download): http://github.com/codeguy/Slim

Still very much a work in progress, but thought I'd go ahead and get the word out.

Enjoy! Josh

What those PHP guys are unable to understand, is that all the coolness and beauty of Sinatra comes from the lack of () {} $ and other meaningless (it this context) symbols and words, like function and echo.

The same effect is in Clojure, but it is a little bit more difficult to explain.

They're lost the beauty of Lisp (especially Scheme) when they broke the clarity and unambiguity of the syntax pushing all those foreign symbols into it. Moreover, they also renamed and broke most of common idioms, using words that could be better as a variable names instead of keywords.

So, it is not a Lisp dialect, even not so-called Lisp-1. It is just yet another JVM-targeted pseudo-functional language, which, OK, looks like lisp to those who never seen a Lisp before.

But, its cool (and ugly), I must admit. ^_^

What those PHP guys are unable to understand, is that all the coolness and beauty of Sinatra comes from the lack of () {} $ and other meaningless (it this context) symbols and words, like function and echo.

i think "those php guys" are well aware that their language is not ruby and care more about getting work done than whether they have to type dollar signs and brackets.

I think c00p3r makes a valid point.

PHP makes it very hard to write "beautiful" frameworks like Sinatra. There's a whole bunch of crufty looking stuff in PHP that is unavoidable.

That doesn't stop me from writing PHP and getting-shit-done. That's an entirely different argument though.

Getting work done is a different goal, and, indeed, an understanding that it is impossible to repeat Sinatra isn't required for getting work done.
Basically what you're saying is that all the beauty of Sinatra comes from Ruby, I disagree.
Without a beauty it is just a dispatcher. There are thousands of them.
Aside from this being "Sinatra clone" #100, I think most people do not understand that Sinatra is about much more than its query and before/after-filter DSL: Its about its plugin API, its great integration into Rack (which PHP doesn't have, middleware solutions or not), its ability to host multiple apps in one process and its large and well-written documentation.

It is easy to implement the query API in any language that supports anonymous functions, but that doesn't make it Sinatra.

This one is not even a good example of a clone: its really bare, only implements the minimal set to "look like sinatra". It doesn't even have a good request or response object.

Heh, it's funny you should mention that.. I had a go at a Sinatra + Rack style framework in PHP a little while ago.

Check it out:

http://github.com/dhotson/kelpie

http://github.com/dhotson/kelpie/blob/master/demoapp.php

It's got its own Rack style web server built in ... kinda crazy huh? ;-)

It looks nice and much cleaner :). Is there a reason for the use of doc comments?

My problem in the PHP world is: you have your Rack-style server. Another project has a different style. In Ruby, every framework nowadays is on Rack.

No particular reason it uses docblocks.. it's just what I thought looked decent at the time. I'm usually not a fan of comments as code, but in this case it's kinda neat.. :-)

It's a real challenge to make nice looking mini languages in PHP. At least Ruby gives you a bit more rope to make clever little languages. /envy

But yeah, I really wish PHP had a web server interface like Rack that was more widely accepted. The two that look the most promising are:

http://mongrel2.org

http://github.com/indeyets/appserver-in-php

Also, the downside of implementing your own web server is that basically zero existing PHP code will work with it. It's because you have to re-implement all the usual superglobal stuff $_GET $_POST $_SESSION etc..

.. I consider that a plus. ;-)

Well, Mongrel2 sort of acts like a common web interface, but only if the other side adopts it.

It really depends, frameworks like Agavi do not use $_GET etc. and explicitly disallow their use.

Can I get some thoughts on http://github.com/luciferous/pip? It's an interface and a web server (and framework). Its a ways to becoming near a standard. I think it "fights" PHP style in its current state.
Looking pretty good. Nice one. :-)

I can't claim much credit for the design of Kelpie, it's mostly a direct port of Ruby's Thin web server. I guess there's a couple of notes I'd make:

- I'd recommend using the mongrel http parser rather than implementing your own. I wrote a PHP extension for it - http://github.com/dhotson/httpparser-php

Also, some cosmetic stuff (feel free to ignore):

- I prefer camelCase for methods

- public/private access control on methods

- PHP namespaces look and act weird to me so I don't use them

- I prefer using underscores in names and a classloader to avoid require statements

Thanks for that! I was looking at your PHP extension a few months ago, but didn't come to a decision on integrating something that users would need to install in addition to the standard PHP package. I'm definitely thinking a lot about the cosmetics of the code, especially since looks different from PEAR etc...
Ah yep, I guess it'd be good to have a pure PHP fallback for HTTP parsing.

Also, I've pretty much developed my own PHP style. I don't follow PEAR conventions.. I go with what looks clearest to me. So obviously you'll want to take my advice with a grain of salt.