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.

Published in #Living on the edge