In this new post to the symfony blog, there's an update on the framework's latest version, Propel integration and the addition of the sfDoctrinePlugin.

After more that two years of development, the Propel team has released Propel 1.3 yesterday. This is a great achievement as Propel 1.3 sports a lot a new exciting features.

These features include PDO integration, object instance pooling, improvements to the date handling features and the addition of more default values for database schemas. There's also the updates with Doctrine:

As announced in the symfony 1.2 roadmap, Doctrine 1.0 will be officially supported and the sfDoctrinePlugin will be bundled with symfony 1.2. Doctrine 1.0 beta1 has been released two weeks ago and the Doctrine team will release Doctrine 1.0 final on September 1st.

In this new post to his blog Stefan Koopmanschap looks at a plugin for the symfony framework that has him impressed.

Using this plugin, it is not necessary anymore to really care about which ORM you pick for your project. It's the thought behind symfony 1.1 taken into the symfony ORM-selection.

He points to the DbFinderPlugin as an alternative to rewriting up the ORM code for your application by hand (or in something like Propel or Doctrine). It makes switching between ORM layers simple - just a configuration change to point to the new system.

On the Ibuildings blogs, there's a new post from Stefan Koopmanschap taking a look at the latest major release of the Symfony PHP framework (v1.1) and some of the functionality it includes.

The official stable release of symfony 1.1 is now nearly a month old, and response so far has been fairly positive. This is not surprising, as this new version adds a lot of flexibility to the already flexible system that symfony offered. Let's have a look at symfony 1.1, and specifically to the points that I feel are especially exciting in this new release.

He looks at the new architecture of the framework, how it now handles forms, the improvements to the plugin system and the (partial) integration of the Propel ORM layer for accessing databases. The full listing of updates can be found here.

The Oracle Technology Network has a new article posted looking at a basic application that combines the power of an Oracle database with the flexibility of the Symfony framework.

Where should someone who wants to learn Symfony begin? Project Symfony has a very informative and well-kept Web site, with extensive documentation. As it turns out, there is a book about Symfony and there are also numerous tutorials-unfortunately all of them created using a MySQL database. That is, in essence, why I decided to write this article about Symfony and Oracle. It's not a full-blown tutorial, but I hope it will be helpful to those who want to use Symfony with Oracle.

The sample application uses the latest version of Symfony, an Apache web server and the Zend Core for Oracle to install and configure the needed setup. The bulk of the tutorial is taken up with examples of how to tell the ORM layer of Symfony about your database tables and how to build the default classes from them.

Francois Zeninotto has posted a comparison of three different ORM (Object Relational Mapping) layers for PHP - Propel, Doctrine and sfPropelFinder (the last being a plugin of the symfony framework).

When it comes to ORMs, it's all a matter of preference. Is it, really? This post compares side-by-side the code required to perform some simple operations with three OO database requesting API. The purpose is to demonstrate that productivity, and not only style, can vary a lot depending on the ORM you choose.

He's worked up a long list of examples including methods to:

• Retrieving an article by its primary key
• Retrieving the latest 5 articles
• Retrieving articles based on a complex AND/OR clause
• Retrieving articles authored by people of a certain group
• Retrieving an article and its category by the article primary key
• Retrieving articles and hydrating their author object and the author group

Each one comes with their own (usually simple) code. His conclusions point out different "bests" of each - like sfPropelFinder being the "most magic" and that some of the limits of Propel are very frustrating.

In this new post to the Symfony blog, Nicolas Perriault shows how to quickly and easily internationalize your Propel forms in your Symfony application.

It has never been so easy to internationalize your Propel forms. In this post, you will learn how to leverage the new form framework bundled with symfony 1.1 to develop an interface to edit articles in several languages.

He uses a basic form layout and shows how to build out the files (via a build-all) and what it ends up looking like. He configures the two languages - English and French - that he wants to use in the form and pushes it through the CRUD generator to make a full web interface for it.

A new post over on the Symfony blog today show how to combine the framework with the Propel templating system thanks to some new enhancements.

Starting with symfony 1.1, it is now possible to easily use Propel 1.3 in your project to take advantage of its speed improvements, nested set implementation, object instance pooling, among others. Most importantly, Propel 1.3 uses PDO instead of Creole as the DBAL, offering a significant performance boost.

There's a few steps to getting everything all set up, but they're pretty simple. First, you'll need to grab the right plugin from the Symfony repository, then you change the yml file configuration for the PDO connection, change a few settings in your propel.ini and clear the cache and rebuild the models - you're all set! (Complete commands and example configurations are included)

In a new post today, Martynas Jusevicius shows how to combine a little SQL magic with the Propel framework to fins the distance between two places:

Eventually the simple distance formula that I have blogged about turned out to be too inaccurate, even for locations within city bounds. I needed to use a formula to calculate great-circle distance which takes into account that the Earth is a sphere.

He includes the SQL to pull the data in the right format and the PHP code (using Propel) to reproduce it without having to write it by hand (complete with the bind variables to help with security and consistency).

The Zend Developer Zone has a new tutorial posted today that talks about the integration of one of the more popular database abstraction/relational mapping tools for PHP5 with the Zend Framework. Specifically, it picks up where this article left off.

One area that the article did not mention was, how does the app know which model will be used? I mean, let's say a client clicks on the link "controller/action", do I have to wait for the front controller to dispatch the request to the controller before knowing that it was called? That is, the model is known explicitly by my app only when I'm in the requested action.

He notes a pretty simple solution to the problem - using the Zend Framework plugin system to create an interface between the application and the model classes that Propel generates.

In a new entry to his blog, Fabian has posted a patch he's developed help get things running faster with Symfony and Propel:

I found the sfBuilders that are responsible for stripping the comments from the generated propel classes and also saw that there is a addIncludes parameter in propel.ini. Lets reuse that and modify the Builders to strip the inline includes and requires.

What he describes as a "tiny step" can help you squeeze that much more performance out of your Symfony application. You can download the patch file here.