

Laravel 4 Beta released - stormpat
http://four.laravel.com/

======
znowi
It 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:

<https://github.com/laravel/laravel/archive/master.zip>

------
wldlyinaccurate
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>

------
jasonlewis
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>

------
bilalq
Awesome. I was waiting on documentation before trying this out. I love that
they're using Composer now.

------
davedx
Exciting! I've been using Laravel for all my new freelance PHP projects, and
I'm really happy with it.

------
wesley
Form and HTML helpers have been removed it seems, I wonder why?

~~~
bilalq
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...](https://github.com/jasonlewis/jasonlewis.me/blob/master/articles/laravel-4-illuminating-
your-laravel-3-applications.md#the-loss-of-html-and-form)

~~~
wesley
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?)

~~~
jasonlewis
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.

------
perishabledave
Can't seem to find a changelog, got a link for whats new?

~~~
stormpat
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/>

------
camus
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/

~~~
stormpat
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."

~~~
camus
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.

~~~
fooyc
file_get_contents only returns the content of the given file; you must be
speaking about something else

