Symfony Resources Central - discussion

Towards symfony 1.1

Romain Dorgueil — Mon, 16 Jun 2008 23:55:00 +0200

After more than one year since symfony 1.0 was released, symfony 1.1 goes more and more mature each day. Recent RC releases are a proof of it, but many people are still concerned about whether or not they should migrate.

Documentation?

Many people are complaining about the fact it lacks documentation. In fact, it seems that many people fears that because François announced he was leaving the symfony core team, nobody would take care of documenting the project.

But that's something any big open-source project come to see one day, a former or important team member leaves the project, because he or she doesn't have anymore time for it, differ views, change interest, or whatever else.

As he said, no-one is irreplaceable, and new people comes in too, hopefully. Developpers from many countries started recently to fix and translate existing documentation for symfony 1.1, a new mailing list is being created for documentors and the symfony core team is currently putting a great effort on it too.

Documentation!

The symfony documentation page is split by version and language, and the 1.1 english version is getting attention to adapt parts of it in the need. But even without that, if you know symfony 1.0 pretty well, you should not have hard time to updating, as every changed part were because they were judged too complex, or not "clean" enough. The new way to do things is usually easier.

To demonstrate it, people from symfony core team published a little serie of articles on symfony-project.org recently:

Nicolas Perriault published an article about form internationalization, something you could not do to do so easily with symfony 1.0 helpers.
Fabien Potencier demonstrated how handy was the new sf_format feature, to provide the same logical content within different formats, or for instance, different views. He also explained how to customize a project's directory structure, showing the use of ApplicationConfiguration and ProjectConfiguration classes.
Carl Vondrick explained how to use Propel 1.3 to boost your ORM layer performances (be aware though that PHP 5.2 is needed, while symfony 1.1 only requires PHP 5.1.4).
I published two little tutorials about sending emails and using tasks.

And more are to come, of course!

And about forms?

The only part of symfony which needs a bit of learning is the new form framework, which is quite radically different from the 1.0 way to create form. And about this, Fabien recently announced he will publish an entire book about it.

To migrate or not to migrate

Symfony 1.0 is Long Term Support version, which means that symfony team will go on fixing bugs for three years since the original release. If your project is nearly released or already released, I would not bother upgrading, because you would not benefit of symfony 1.1 new features, while you'd suffer the upgrade process.

On the other hand, if your project is very young, I think the time to take the step is now, the official 1.1 release being real soon. You'd benefit of all new features with a very active community and a very reactive development team.

I'd like to hear a Kwatuor play nice symfonic music

Romain Dorgueil — Tue, 26 Feb 2008 23:58:00 +0100

Today's post is a bit special.

This can be took as a question.

Or a call to developpers that have specific blogging needs.

Since quite a moment I used dotclear for blogging. That suit my needs, in some way, but maybe I'm more adaptating my needs to dotclear's capabilities. Maybe you're using wordpress. or any other. And I guess that must be the same for you, thinking for example of integrating one of those all-in-one blogging/cms platforms cleanly in another website, for example, is being more than utopian...

By clean I mean integrating it without having to duplicate the template. Neither having to use all functionalities if you only need a simple article list somewhere... And without being limited if you need to display the headers of those on another website...

I'd better not speak of blog networks communicating, or taking content from RSS/XML/anything feed in a flexible way.

So today I'd like to announce the birth of Kwatuor. Kwatuor is a blog platform project using symfony and doctrine, that will in the near future use doctrine migrations to get content from an existing dotclear/wordpress project, or any other source platform someone has enough need with he'd take the time to write migration classes for.

Templating system will be different. I'm still hesitating between a generator approach (generated partials from a dynamic skeleton, that all can be customizable) and a real proper template system (but still any part would be customizable). Only major difference with blogging platform would be the total forbidding of DRY-breaks a dotclear-like templating system is doing everyday. And this extends to integrated blogs, in wider projects.

In fact I started developing it for my own needs, but I think this is typically the kind of project everybody would need someday. Maybe you hate being jailed in your obscure, yet very good, but specific and... even more obscure blog platform.

So I'm wondering now, if people (you :p) would be interested in this project. If so, I'll make a public SVN/trac next week, so concerned users will be able to give feedback with code in their hands. Would this be usefull to you? Would you contribute to this open-source project? Do you have good (or bad :p) ideas about concepts to take in consideration from the beginning?

Related links

Doctrine Migrations

Testing Symfony 1.1

Romain Dorgueil — Sun, 28 Oct 2007 12:03:00 +0100

Wondering what symfony 1.1 will look like? Well, I couldn't hold my curiosity neither, so I upgraded one of my websites to symfony 1.1, and I describe here how to setup a box to run both versions. The upgrade process being definitive for a given project, make backups or svn commit before upgrading.

WARNING: Symfony 1.1 is a development version, and should not be used for production. Use it at your own risks.

First of all, i did not want the upgrade to be definitive, I needed a simple way to go back to older version. But SVN would handle this, no problem. On an other side, I needed to keep the two symfony version running on the same box, as other sites are running on it.

My approach to it was to checkout the symfony trunk/lib and trunk/data in /usr/share/pear/symfony1.1 and /usr/share/pear/data/symfony1.1 respectively. This way, i can switch any project I want to symfony 1.1 by changing the config/config.php to use the development version paths.

cd /usr/share/pear/
svn co http://svn.symfony-project.com/trunk/lib symfony1.1
svn co http://svn.symfony-project.com/trunk/data data/symfony1.1

That should retrieve a local copy of the latest development version on your computer.

Upgrading a 1.0 project

To upgrade a project, your first need is to tell the symfony batch script where to find its libraries. Hopefully, symfony's structure permits to set per-project library paths by changing config/config.php. Edit this file and replace the file content by the new 1.1 paths

// symfony directories

$sf_symfony_lib_dir  = '/usr/share/pear/symfony1.1';

$sf_symfony_data_dir = '/usr/share/pear/data/symfony1.1';

You can test your changes were effective by typing symfony in your project directory. You should now see the new namespaced pake tasks that come with symfony 1.1. As in every version, an upgrade pake task that automates the changes you have to make to your project to make it work with the new version is given, and you can do:

symfony project:upgrade1.1
symfony cache:clear

(Note that old symfony cc alias still exists for the cache:clear task)

At this point, I tryed to see if my project would be working, but a nice uncaught LogicException was showing up in development environment, and I had to manually change %project_dir%/apps/*/config/config.php (look at spl_autoload_register line...).

After a little investigation, i found that running the task twice would autocorrect it, and that it was a little problem in lib/task/project/upgrade1.1/sfAutoloadingUpgrade.class.php, so i sent a ticket on Symfony's TRAC.

Now you should have your project up and running.

Generating a new 1.1 project

That's easier than upgrading, but the only (little) difficulty comes from the fact that 'symfony' script will look for 1.0 libraries. For this, you'll create a copy of /usr/bin/symfony to /usr/bin/symfony1.1 (you'll need to be root for this), and change its content to:

#!/usr/bin/env php

<?php



/*

 * This file is part of the symfony package.

 * (c) 2004-2006 Fabien Potencier <fabien.potencier@symfony-project.com>

 * 

 * For the full copyright and license information, please view the LICENSE

 * file that was distributed with this source code.

 */



// project exists?

if (file_exists('config/config.php'))

{

  include('config/config.php');

}



if (!isset($sf_symfony_lib_dir))

{

  if (is_readable(dirname(__FILE__).'/../../lib/VERSION'))

  {

    // SVN

    $sf_symfony_lib_dir  = realpath(dirname(__FILE__).'/../../lib');

    $sf_symfony_data_dir = realpath(dirname(__FILE__).'/..');

  }

  else

  {

    // PEAR

    $sf_symfony_lib_dir  = '/usr/share/pear/symfony1.1';

    $sf_symfony_data_dir = '/usr/share/pear/data/symfony1.1';



    if (!is_dir($sf_symfony_lib_dir))

    {

      throw new Exception('Unable to find symfony libraries');

    }

  }

}



include($sf_symfony_data_dir.'/bin/symfony.php');

You can now run

symfony1.1 generate:project

in a new directory to have a 1.1 project skeleton built there.

Have fun with it, I'll post articles about the new form/validation system and upgrading your doctrine schemas to the rewritten sfDoctrinePlugin (that works both in 1.0 and 1.1) soon.