Symphony.

At first I was a bit confused by it, but I am starting to like the composer concept :-D

Thanks for the pull request. I've thrown in a small fix for the current beta. Everything's fine again. And yep, composer is really a big help.

BTW, the normalizer really needs some love for normalizing objects. The main problem that I encountered was resolving circular references on an object/array. So, if you want to dig in, go ahead :)

Thomas, nice start! Installed and playing.

I haven't managed to get twigbridge and xsltbridge working at the same time, which is a bit unfortunate. Any ideas?

I haven't managed to get twigbridge and xsltbridge working at the same time, which is a bit unfortunate. Any ideas?

Why would you have both installed at the same time?

Think of symphony using XSLT templating for the backend and letting the user choose whatever templating language he prefers for the frontend.

Looks like a unanimous consensus!

Okay, this thread started with Laravel and in the end we agreed to move to a framework. So which frameworks are actually in the game? Which are suitable? And why?

It's something that does need some careful consideration as it sets a long term direction going forward. It looks like Laravel is the clear favourite at present but it's always worth considering all the options before making any decisions. My personal favourties would be Laravel or Symfony. Laravel is a framework looking forward taking advantage of the newer PHP releases, ensures compatibility for the future via Composer, and is as modular by nature. Symfony is also modern, powerful and well respected with a well established community. I think others the size of Zend would be overkill and carry too much baggage. They're fine for large enterprise applications but a bit too big and unwieldy for use with Symphony. Cake and CodeIgniter also serve their users well but aren't as modern or dynamic and have also built up baggage in their time on the scene. When thinking about a long term future I think we need to be looking forward.

I'd opt for Laravel but Symfony would certainly be a worthy contender and is has to score a bonus point for the namesake. :)

Think of symphony using XSLT templating for the backend and letting the user choose whatever templating language he prefers for the frontend.

Doh, good point.

Laravel is a framework looking forward taking advantage of the newer PHP releases, ensures compatibility for the future via Composer, and is as modular by nature.

Sums up my thoughts. That and it is enjoyable to use.

In the proposal I'm writing, I'm opting for complete separation of the template layer from the application layer, and have each be it's own instance running on the single framework. It's a little more complicated than that, but basing the application layer on a rest api would mean that everything runs through endpoints, meaning that technically, anything could make requests to the application. If the user was viewing the admin, the application would only start up with the xslt logic, if the frontend, it would only start up with the chosen template layer.

It may have issues I've not looked at yet. It's only a proposal.

What are the troubles you're having Thomas?

John, where are you writing the proposal? Is it public yet?

What are the troubles you're having Thomas?

I chatted with him a bit. It has to do with other template packages overriding the templating engines to be loaded. I think it's just a matter of the different template package authors including the other possible template engines if a package exists.

The proposal is still on my machine at the moment.

I still don't fully understand this packages stuff.

I still don't fully understand this packages stuff.

What in particular?

How two can collide like that. Can't the application be configured differently in different request environments, and only load the configured packages?

The issue is that both bundles register themselves using

$this->app['view.engine.resolver'] = new EngineResolver;
$this->registerTwigEngine($renderer);

and

$this->app['view.engine.resolver'] = new EngineResolver;
$this->registerXsltEngine($renderer)

effectively overwriting each other's instance of EngineResolver. Due to some weird closure stuff it currently seems to be impossible to have them re-use whatever exists in $this->app['view.engine.resolver'].

And: You don't want the framework to be configured differently depending on wich request you receive as it could result weird, unexpected and untested behaviour. The solution would be to find a way to have both Engines register in one common EngineResolver.

New Laravel 4 video porn: HTTP Basic Auth, Cache Sections, Redis Clustering, Eloquent Touch, Whoops.

You don't want the framework to be configured differently depending on wich request you receive as it could result weird, unexpected and untested behaviour.

So, if I used a Route of /symphony I couldn't register and use the XSLTProcessor, and on any other Route, use another one?

That just sounds weird to me.

You register the Engine for a certain view fileextension. home.xsl will be rendered by XSLT, home.twig by Twig. But all Engines are registered at any time (not instanciated though).

I've fixed this issue and sent pullrequests to the two Bridges.

I know there's been some comments about 'what framework should we use'. I'm throwing a vote behind Laravel. It's an exciting framework and has galvanised the community. Building Symphony on an innovative framework will be great for adoption and community buzz and I'm excited to see where it leads.

Part of Symphony's Tao is to lean and only providing what you need, and this is something that I think Laravel is more suited to rather then something like Zend or Symfony.