Symfony Resources Central - 1.1

Symfony 1.1 is out, and the winner is... 1.2!

Romain Dorgueil — Tue, 01 Jul 2008 23:52:00 +0200

The longly awaited 1.1 version is finally out after long months of development. After doing this, Fabien started the 1.2 branch, and you can take a look at that magnificient revision which for sure opens a new era of symfony developments.

A lot of nice new features are greatly awaited in the next version.

First of all, the admin generator will be completely rewritten, to make a good use of the new form framework. That will for sure open incredible new possibilities and remove the permanent need for hacks to customize your own admin interface (or frontend interface, if you do use admin generation in frontend too). At least, the first one amazed more than one person, and we can be pretty sure that new version will kick asses.

Some people were complaining about Ruby on Rails having a great advantage over symfony, by their deployment tool Capistrano, while symfony only allow to rsync to one server. Hopefully this won't be true for long anymore. For information, Capistrano allows to create real deployment scripts, like "Disable frontend app on this server, make backups of site and database, synchronize, remotely run tests, clear the cache and enable the frontend app". That will easify a lot our projects delivery procedures.

Amongst some other details, the last major point Symfony 1.2 will see is some further decoupling of the technical choices symfony 1.0 gave us, like Propel or Prototype. Prototype and the helpers will still be bundled with symfony, but as a plugin, like Propel is since 1.1. This is very important IMHO, because symfony should never force any technical choice to the teams. But many people complained that helpers was one of the easy and magic things that attract newcomers to symfony. The plugin solution is keeping everyone happy. In the same spirit, symfony 1.2 will bundle the sfDoctrine plugin thanks to Jonathan Wage work to stabilise and manage branches/features.

And for the short term, the unpublished chapters of the form framework online book are still to come too, along with a symfony 1.1 "First project" tutorial.

Long life to symfony :-)

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.

sfForms11Plugin: use symfony 1.1 form/validation framework in symfony 1.0 or non-symfony project

Romain Dorgueil — Mon, 07 Jan 2008 23:32:00 +0100

The new symfony 1.1 form/validation framework is 100% symfony-independant, and though is not limited to the (very) awaited 1.1 stable release. To use it in your own symfony 1.0 projects, you can use sfForms11Plugin. It's content is very thin: it only sets up externals to symfony 1.1 form/widget/validator libraries.

To use it, simply add the following external to your project:

sfForms11Plugin http://svn.symfony-project.com/plugins/sfForms11Plugin

Or check it out from your project base directory:

svn co http://svn.symfony-project.com/plugins/sfForms11Plugin plugins/sfForms11Plugin

Let's try it...

Now you'll be able to define sfForm sub-classes to materialize forms:

class HelloWorldForm extends sfForm

{

  public function configure()

  {

  }



  public function setup()

  {

    $this->setWidgetSchema(new sfWidgetFormSchema(array(

            'name' => new sfWidgetFormInput(),

            )));



    $this->setValidatorSchema(new sfValidatorSchema(array(

            'name' => new sfValidatorString(array('required'=>true, 'min_length'=>1, 'max_length'=>50)),

            )));



    $this->widgetSchema->setNameFormat('hello[%s]');

    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);



    parent::setup();

  }

}

This class define the model of your HelloWorldForm, and you can now use it in your actions:

class testActions extends sfActions

{

  function executeHelloWorld()

  {

    $this->form = new HelloWorldForm();



    if ($this->getRequest()->getMethod() == sfRequest::POST)

    {

      if (null !== ($hello = $this->getRequestParameter('hello', null)))

      {

        $this->form->bind($hello);



        if ($this->form->isValid())

        {

          $this->redirect('@hello?name='.$this->form->getValue('name'));

        }

      }

    }

  }

}

At this point, the only little detail still missing is the view, containing actual form display:

<form method="POST">

<table>

<?php echo $form; ?>

<tr>

  <td colspan="2" align="right">

    <input type="submit" value="Greetings, Mr Computer!" />

  </td>

</tr>

</table>

</form>

That's it! You now have a simple form, self-validating, protected against CSRF attacks and redirecting to some place if values entered matched our sfValidatorSchema.

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.