URL Routing in Recess my upcoming PHP Framework
recessframework.com
recessframework.com
I can't wait! :)
Also liking the deployment and dev modes & the tools app (which is a killer feature IMO!).
How far off complete is it?
Preview bits will go out to folks on the mailing list this week. There's a fun road ahead in bringing the framework to maturity - but there 'core' meat of the framework is solid and a nice departure from the current state of PHP frameworks.
Might you consider dropping the bang in "Recess!"? I can't imagine a more annoying naming gimmick. It's not so bad when the name is used alone but it really messes up the reading when it's in a paragraph.
In Sinatra you don't even need the methods. For example:
get '/say/*/to/*' do
# put code here
end
post '/somewhere_else' do
# put code here
end
When debugging an application someone else has written, generally I'll be given a problem - and I want to find out all the code behind whatever is broken or needs looked into. So you start from a URL, go to your centralised dispatcher router whether that be your Zend bootstrapper, a mod_rewrite rule in a .htaccess file, your django URLs file or.. whatever. From there you'll be able to work out which controller and action you need to look at. In this case I'm looking through a whole bunch of controllers and then their doccomments to see which route matches. Not pleasant.
As someone said, this is pretty clever, but I'm not convinced it leads to maintainable code. Which is the entire point of frameworks and the MVC pattern. There are other ways to implement DRY in a dispatcher without resorting to inlining a pattern into a comment. For example, you could delegate a base pattern to another URLs conf like you do in django.. or use nested routes like the Perl Mojolicious framework:
http://search.cpan.org/~sri/Mojo-0.9/lib/Mojo/Manual/Mojolic...
From the very brief sneak peek we got at that it looks like a killer toolset for something lie what you describe. Knowing where to head to BEFORE even opening a controller file is a big bonus :)
Me and a friend are looking for a good php framework to build an application on. Any idea on when this will be out?
The support for methods and paths is very cool. Is there any support for media types/content negotiation?
Content negotiation is on the radar. Currently the negotiation is one-sided and depends on the request having a .json extension for example. This will be beefed up after the preview release.
Essentially, you're moving a part of your functionality (the part that determines which URLs exist, and which parameters are defined in those URLs) from a programming language environment to a common language environment (the comments). That common language environment is not as capable when it comes to defining, specifying or altering functionality - but it's what a programming language excels in.
So what do you do if you want to generate URLs? Or if you want to define URLs based on some content in the database? Those are hard things to accomplish with your current approach. I assume that there's a proper API that might address such issues, but the article doesn't mention such a thing. Good luck though.
CakePHP, (http://book.cakephp.org/view/46/Routes-Configuration) for example, can do all of what this does out of the box without the need for an application to monitor your routes.
REST also seems very well implemented : http://book.cakephp.org/view/476/REST
Am I missing something? Can someone explain the benefits?
Am I the only one here who finds this ugly?
Have you thought about using "named" variables for this sort of functionality without interfering with the commenting system.
Design decisions have been made to err in the favor of making user code simple and more expressive. Having some routing logic contained in the code and 'pretty urls' in mod_rewrite is much more difficult to approach.
If the former is true (you're already getting the param names), then there's no further overhead to map directly to $_REQUEST. I forget the exact Reflection syntax, but wouldn't it just be something like
$argsToPass = array(); $args = ReflectionMethod->getParams(); //you got an array of param names in the order they appear in the function foreach ($args as $arg) { if (!isset($_REQUEST[$arg])) { //check if the arg is optional and fail if not } $argsToPass[] = $_REQUEST[$arg]; } $ReflectionMethod->invoke($argsToPass);
I haven't touched this stuff in a while, so I might be completely off, but I'm not sure what overhead you're referring to...
Once again, I'm not defending this approach, as the extra logic you've put in to interpret the path probably makes things a lot more flexible and easier to debug.
The names are important in mapping so... / !Route GET, $last/$first */ function foo($first, $last) {...} Maps $first to $first properly, etc.
Indeed the hope is that this will be easier to understand and use.
Attributes are a way of declaratively making a statement at a more "meta" level. Because doccomments are a first class language construct in PHP (i.e. Reflection provides doccomments for you) it seemed the most appropriate place for providing additional metadata.
Ultimatley PHP short syntax is just simpler (especially if your using an MVC framework or similar).
The other reply also wasn't saying anything about ease. It was about control, which is also important once your team reaches a certain size/level of skill diversity.