Stefan Koopmanschap has a new post to the Ibuildings blog today about symfony's 1.2 release.

The first day of december started well: It meant the release of the new symfony 1.2.0 version. Aside from the additions and improvements in the code, this new branch of symfony also reinstates an old tradition in symfony: It comes paired with a huge amount of documentation in many forms. Let's have a look at what symfony 1.2 has to offer.

He mentions multiple updates and changes to the framework as well as three specific improvements in the realm of documentation - the jobeet advent calendar, a symfony + doctrine book and the constant stream of tutorials coming out of the community.

The symfony blog has a new post spotlighting one of the new features of their 1.2 release - updates to its Doctrine functionality.

A lot of awesome stuff has been added recently to the next major symfony release, 1.2. Fabien has worked very hard to add without a doubt the most sophisticated features of any PHP framework that exists today. Not only are they nice features but he has implemented them in a OO way so that it is easy for me to implement the same features with another ORM, Doctrine. All this is done with very little work by me. So, give a big thanks to him if you enjoy this.

Included in the post is a real-world example showing how to use the symfony command line to build out an environment and create connections to the articles, categories and authors tables.

In a recent entry to his blog Andy Jeffries gives an overview of his site's transition over from one framework to another - away from Symfony and over to Rails.

I decided as I was learning/using Symfony at my contract at the time that it would be a good experiment to write it in Symfony. [...] The site did fairly well when I posted but I still posted in frequently.

After redefining the site's purpose a bit, he reconsidered the language (and framework) choice and decided to do a rewrite in Rails. He gives a comparison of the process on things like lines of code, time to build, performance differences, deployment and automated testing.

As this new post on the symfony blog points out, their next Plugin Developers Day is happening this weekend on Saturday, November 8th.

Preparations for the coming plugin developers day on Nov. 8th are proceeding apace. I've heard from a number of you who are planning to attend, some planning to start development on new, groudbreaking plugins, others looking to help update existing plugins to work with the latest and greatest version of symfony, and still others just hoping to learn from the lively discussion. All types are welcome!

The event will be centered around the #symfony channel on the Freenode IRC network and is broken up into different sections - creating and releasing a plugin, writing a customizable plugin and coding sprints on new/existing plugins.

Kris Wallsmith has posted an announcement to the symfony blog about an upcoming event (happening Saturday November 8th from 3pm-9pm GMT) - Plugin Developers Day.

We will cover a number of plugin-related subjects in depth, including creating and naming a plugin, adding customizable model, form and action classes, unit and functional testing a plugin, packaging and releasing, and what's new in symfony 1.2.

If you've been meaning to try your hand at writing a symfony plugin or have been writing plugins for years, please join some of your fellow developers for a day of learning, collaboration and development.

Its an online event that'll be happening in the #symfony IRC channel on the Freenode IRC network. Nothing to sign up for - just show up ready to learn.

Gopal Vijayaraghavan has posted some opinions about the way that several of the popular PHP frameworks work internally, more specifically in their inclusion schemes.

In the development of things, there comes a point when it escapes the vision and control of one man/one mind. PHP frameworks are such ... beasts. But the simplicity a machine took away can be made to return. And such an attempt at zooming out of the complex file structure bureaucracy of most php projects was inclued.

He points to this image of the Zend Framework's structure as an example of the unneeded complexity several of the frameworks are guilty of (including CakePHP, Symfony and CodeIgniter).

He also includes a suggestion that could help keep the frameworks a bit more accountable:

Now, all that remains is a php-graphviz + svg mode which renders these in-browser as an iframe - or maybe someone can help me with the graph reduction to take a collection of the inclued dumps & create a "package".

Fabien Potencier has posted to the symfony blog today about a form handling enhancement they've introduced in the latest release of the framework (v1.2) - sfWidgetFormChoice.

When displaying a form, you often want the user to make a choice amongst a list of possibilities. In HTML, a choice is represented by a select tag. You can add a multiple attribute to make it accept several choices. [...] To unify all these possibilities, symfony 1.2 comes with a new widget called sfWidgetFormChoice. sfWidgetFormChoice is an abstract widget in the sense that it delegates the rendering to another widget (the renderer widget).

He includes examples of how to use the widget to make dropdowns, radio buttons, check boxes and even integrate some Javascript for handling multiple lists and autocompletes.

Stefan Koopmanschap has a recent post to his blog showing how to embed a distribution of the symfony framework in with the release of your application:

With symfony 1.0, one of the nice features was the freeze option, which allowed you to package the symfony libraries inside your project quite easily. This was very useful, for instance when deploying your project on a server where you couldn't install symfony. With symfony 1.1, it is apparently not advised anymore to use the freeze option (even though it is still available). So how should this be done then? Let's have a look...

He steps through the process, first setting up a subversion repository then putting a copy of symfony in to the lib/vendor directory and use the svn:externals to link to it.

In this new post to his blog Chris Hartjes suggests a new way to judge frameworks - how easy they make it to write unit tests against them and their resulting applications.

As a project for work gets ready for an alpha release, I've managed to eliminate all the serious bugs and now have some time for what should've been part of the project from the beginning: writing tests. [...] Since I'm using Code Igniter instead of CakePHP for this project (did I mention that I inherited the project and couldn't switch?) I started looking into the culture of testing surrounding Code Igniter. It's weaker than a newborn baby.

He tried to find anything he could use to write tests against the CodeIgniter application and finding fooStack as an easy to use tool for the job. This was what made him wonder how other frameworks stack up in the "has good unit testing functionality" category. He briefly covers four of them - CodeIgniter, Zend Framework, CakePHP and Symfony.

So now when you start comparing frameworks to each other, I think it's important you also consider how much effort has gone into creating tests for the core functionality of that framework. A well tested framework should mean far less surprises when using it.

Symfony developers out there will be happy to know that, since the release of symfony 1.1, writing unit tests for your models has been made even easier.

Writing unit tests for your Propel or Doctrine model is much more easier as of symfony 1.1. In this tutorial, you will learn some great tips and best practices to write better tests for your models.

The tutorial walks you through the creating of a simple test - evaluating a few criteria for the database contents. The entire thing is contained inside of YML files and is easily run via the sfConfig and integrated Propel functionality.