Laravel 4 Beta released
four.laravel.comIt looks very nice. If I happen to write a project on PHP, I'll sure give it a try.
They didn't tag v4.0 release on github, hence the zip package link is 404.
https://github.com/laravel/laravel/archive/4.0.zip
You can instead fetch master:
I love Laravel, it's the simplest and most expressive PHP framework that I've used, and it does everything I want it to do out of the box. I really like that Laravel 4's API is practically identical to Laravel 3, too.
Btw you can browse the code on GitHub if you don't want to download it: https://github.com/laravel/framework
The beta hasn't actually been officially announced yet. As of this comment it's still in a pre-beta stage. Taylor will announce the beta sometime on Monday, as per the following tweet: https://twitter.com/laravelphp/status/289880193580032001
Awesome. I was waiting on documentation before trying this out. I love that they're using Composer now.
Exciting! I've been using Laravel for all my new freelance PHP projects, and I'm really happy with it.
Form and HTML helpers have been removed it seems, I wonder why?
Since Laravel 4 is Composer based, these have been extracted away. There are ports of the old HTML and Form helpers from Laravel 3, as well as a new package built with Laravel 4 support in mind. See this for more details: https://github.com/jasonlewis/jasonlewis.me/blob/master/arti...
Still, shouldn't they decide on some kind of default? (Even if it's third party). What will happen to laravel bundles if everyone uses different form libraries in those bundles? (I assume there will still be something different from composer for bundles?)
Well considering bundles have been dropped in favor of packages it shouldn't really matter. There should never be any conflicts because packages should be namespaced in a vendor/package fashion, meaning one package can use Form helper A and another can use Form helper B without conflicting.
Yeah, I kind of wish they left in a default as well. Still, it's not that difficult to include one.
Can't seem to find a changelog, got a link for whats new?
Its a complete rewrite, and there is many new concepts. The syntax is however almost the same. A good list of new features can be found here: http://phpmaster.com/whats-new-in-laravel-4/
The biggest is maybe the use of composer, its really changing PHP for the better.
PHP frameworks are finally becoming sane. Instead of re-inventing the wheel ,they share popular components wether it is from doctrine , symfony , etc ... The PSR stuff and composer is a huge step in the right direction , we are getting there , at last. another promise framework is Silex based on Symfony , it's easy to wire any symfony component through services and unlike Laravel it doesnt rely on Static methods or Singletons. silex.sensiolabs.org/
The problem with static and singletons have been adressed by the creator, Taylor Otwell. Heres a quote (http://forums.laravel.io/viewtopic.php?pid=3237)from him regarding the static methods in laravel 4.
"Yeah, this [static methods/singletons] is something I have thought about a lot.
I have gone from everything totally static, to everything totally dependency injected, to somewhere in between. The criticisms of static methods are certainly valid. If you'll notice in the Laravel core code, the router, session handling, and database stuff is actually pretty thoroughly dependency injected. When the Laravel core creates the session payload, it injects the driver. That allows me to unit test the framework more thoroughly since I can inject mocks and stubs.
Problems I have run into with using DI throughout the framework is that you start to fight against the global state that exists within PHP itself. For instance, functions like "file_get_contents" and "file_exists"... you have to have some way to mock those.
I have actually moved Laravel totally off of static methods before to see what it would be like, and it's not too bad. I think in the future it's possible more classes will be moved off of static methods.
To dig deeper into Laravel, there is actually an abstract "Facade" class that makes you think a class is static when it's not. For instance, when you do "Session::get", you are actually hitting the Laravel\Facades\Session class, which is resolving the session payload out of the IoC container and then calling the method you want. It's a trick to give you convenient access while still keeping the framework somewhat testable.
So, I totally agree with the articles. The struggle so far has just been to find a good balance point for Laravel. Writing testable code is still up to the developer to an extent. You can use the IoC container to inject a database connection instead of just using the DB static methods. However, things like the Input, URL, File, etc. classes still being static could lead to some testability problems. I've broken encapsulation on the Input class just to make it a little more testable. You can set the Input just by saying "Input::$input = array()".
This is probably way more information than you wanted, but just letting you know this is something I have thought about a lot. Symfony2 has probably done the best job of keeping things testable that I know of. I think Laravel's testability is decent as it stands, but I know there are things that could make it better."
file_get_contents is an interesting one , it creates variables out of thin air ( though i think the scope stays "local") when called from a function.
file_get_contents only returns the content of the given file; you must be speaking about something else