• Fabien Potencier
• 10 months ago
• Living on the edge
• 4

As for every symfony version, we try to simplify the API and make it more intuitive and powerful. Here are some examples that you will soon enjoy in symfony 1.2.

Application name in CLI tasks

Some Propel tasks take an application name as an argument because they need to connect to the database. This is sometimes counter-intuitive as some other Propel tasks do not require this argument.

As of symfony 1.2, this argument has been removed in favor of an optional "application" option. If you don't provide the "application" option, symfony will take the database configuration from the project databases.yml file, which is the behavior you expect most of the time.

The propel:build-all-load now behaves like any other propel:build-* task:

# symfony 1.2
./symfony propel:build-all-load
 
# symfony 1.1
./symfony propel:build-all-load application_name
 

You can also load data fixtures or dump your database to YAML with the following commands:

./symfony propel:data-load
./symfony propel:data-dump
 

Of course you can still provide an application if you need a specific configuration:

./symfony propel:buil-all-load --application=frontend
 

Native PUT and DELETE support from the browser

You can now simulate PUT and DELETE requests from a browser by using the POST method and by adding a special sf_method hidden parameter:

<form action="#" method="POST">
  <input type="hidden" name="sf_method" value="PUT" />
 
  <!-- // ... -->
</form>
 

With such a form, a call to sfRequest::getMethod() will return PUT. Stay tuned for more new features that will enable easy and native RESTful applications in symfony.

Shortcuts in the response

Sometimes, you need to get the stylesheets or the JavaScripts from the current response. But the getStylesheets() and getJavascripts() method returns the internal representation of the information, which is not what you expect.

As of symfony 1.2, these two methods return the information in a ready-to-be-used, de-duplicated, and ordered format:

array(
  'bar.css' => array(),
  'foo.css' => array(),
)
 

sfValidatorSchemaCompare validator

The sfValidatorSchemaCompare constant values have been changed. The following two examples are now equivalent:

// symfony 1.1 and 1.2
$v = new sfValidatorSchemaCompare('left', sfValidatorSchemaCompare::EQUAL, 'right');
 
// symfony 1.2 only
$v = new sfValidatorSchemaCompare('left', '==', 'right');
 

The new one is much more readable and intuitive.

Comments

• 

  #1 Taku said about 13 hours later

  Small but great, thanks for keeping us in touch, the REST-thing is great.

  Courage, guys, can't wait for this 1.2 :-).

• 

  #2 Taku said about 14 hours later

  Just a question ?
  Will the François REST-thing be included in 1.2 (I mean this : http://redotheweb.com/2008/08/08/add-request-method-requirement-to-routing-in-symfony-11/ ). It seems to be great and a good complement of the sfForm REST thing exposed here...

• 

  #3 Markus.Staab said 1 day later

  @Taku:

  something like that was introduced with the latest routing refactoring

  see http://trac.symfony-project.org/changeset/11313

• 

  #4 Taku said 1 day later

  Great news !
  Thanks for the information Markus.Staab, things are going well with this 1.2. 'Feel it will be a great release :).