Tag cloud
Subscribe to this blog
Ibuildings BlogsStefans Blog
 |
Stefan Koopmanschap Professional Services Consultant Stefan is one of our Professional Services Consultants; he performs audits, development team assessments, training, and technically challenging development projects. Stefan is an advocate of the Symfony framework and runs the Dutch Symfony Portal. |
 |
Tuesday, July 29. 2008
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.
ArchitectureThe big reason for symfony 1.1 to take quite a long time, for a reasonably small version jump, was the complete refactoring of the underlying symfony code base, which Fabien Potencier has named the symfony platform. This code base consists of a fully decoupled set of base functionality such as session handling, caching, logging, form handling, and much more. The symfony platform can be used independently of the main framework, but this architecture also allows to easily swap out one of these parts and replace it with a custom solution if you have specific needs. A full overview of this new architecture can be found in this symfony blog post. Form handlingThe old symfony form handling has been taken out, and replaced by a new form framework. This form framework can do anything from form building to form validation, and with the Propel integration it can even save the data directly to the database (after you validate it of course!). The new form framework is really extensive, extensive enough for the symfony team to decide to write a full book on it. PluginsThe plugin system in symfony is now fully compatible with the PEAR API. This is especially important for dependencies. With symfony 1.0, if you wanted to install a plugin that had dependencies on other plugins, this meant having to manually install all dependencies. With the new plugin system in 1.1, dependencies are automatically installed by installing the plugin you want. ORMPropel (1.2) is not fully integrated anymore in symfony 1.1, but delivered as a plugin. It is still installed by default when you install symfony, however having Propel integrated as a plugin makes it a lot easier to switch to Doctrine, or for instance install the sfPropel13Plugin. With the recent announcement that Sensio, the company behind the symfony project, is sponsoring the further development of Doctrine, it is clear that symfony is heading in another direction for the ORM. But there's more...The full list of changes is available in the symfony 1.1 announcement post on the symfony blog. The above gives the highlights of the best changes, but there is much more. So now what?Existing projects, and even new projects, can still safely be built in symfony 1.0. Sensio has given the commitment to officially support the 1.0 branch of symfony for years to come, until january 2010. However, in a lot of cases, the advantages of symfony 1.1 will be big enough to go for that. If you still want to use 1.0 though, not a problem. Some changes, such as the CSRF protection and the new form framework, are backported to symfony 1.0 in plugins. So part of the power can also be used in symfony 1.0. And the future?Symfony's future looks bright. Symfony 1.1 has just been released a month ago, and symfony 1.2 is already on the horizon. The release date for symfony 1.2 has been set to october 2008, and the roadmap for this release is also available already. It doesn't look like this project will be going to sleep any time soon. Comments
Display comments as
(Linear | Threaded)
Does decoupling of the ORM mean that Symphony is moving towards a use-at-will architecture (á la ZF)?
Yes, this is where symfony is heading. The same is going on with the Javascript framework plugins. Prototype used to be included, but it is now a plugin. So you can also install Dojo, jQuery, or whatever other plugin for this.
The problem with ZF is, at this point, that it's not decoupled enough anymore for use-at-will. More and more internal dependencies seem to pop up, making it harder to only use a specific component. Those components in the symfony platform are truely and completely seperated though.
Sounds nice, i have to determine if it is useful to change from propel to doctrine is there a big andvantage in performance coming with doctrine ?
Hi Johny,
If you are currently using the standard Propel 1.2, there is big performance gains to get when switching to Doctrine. Another step you could take is to use the Propel 1.3 plugin. Propel 1.2 is horribly slow compared to those two. Francois Zaninotto wrote a plugin (sfPropelFinder) which brings the Doctrine query building API to Propel, so this is not a very good reason anymore to switch to Doctrine. But still, Doctrine works quite good in this and is of course the original of this API.
You should give Django a go once. It has some really awesome features
It is on my list, but since that will require me to get into a new language as well, it's low on my list of things to do
It took a collegue of mine a few months to actually convince me to try it. Python is not that hard to learn, quite a fun language to work with
Both frameworks are really excellent.
I guess I'll better wait for symfony 1.2 and see which direction it will be moving. For now improvements in 1.1 does not look absolutely great and I decided to wait until fall (1.2 was promised to appear in october or so)
|
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 amoun
Tracked: Dec 03, 10:38