Master Symfony2 fundamentals

Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).
trainings.sensiolabs.com

L'audit Qualité par SensioLabs

200 points de contrôle de votre applicatif web.
audit.sensiolabs.com

New in symfony 1.2: Small things matter (3) by Fabien Potencier – October 08, 2008 – 9 comments

Here comes the third edition of small things that might make you happy in symfony 1.2.

Tests coverage

When you test your code with unit or functional tests, it's quite handy to know if some code has not been covered.

As of symfony 1.2, the test:coverage task outputs the code coverage for some given tests:

./symfony test:coverage test/unit/model/ArticleTest.php lib/model/Article.php
 

The first argument is a test file or a test directory. The second one is the file or directory for which you want to know the code coverage.

If you want to know which lines are not covered, simply add the --detailed option:

./symfony test:coverage --detailed test/unit/model/ArticleTest.php lib/model/Article.php
 

Code coverage

Events

The event system introduced in symfony 1.1 makes the framework quite flexible. As new needs arise, new events are added:

  • user.change_authentication: notified when a user authentication status changes. The event takes the authenticated flag as an argument after the change occurred.
  • debug.web.load_panels
  • debug.web.filter_logs

You can read the web debug toolbar post to learn more about the new debug.* events.

Forms

The form framework is made better by the addition of several methods that simplifies its usage in the templates:

The renderUsing() method renders the form using a specific formatter:

// in a template, the form will be rendered using the "list" form formatter 
<?php echo $form->renderUsing('list') ?>
 

The renderHiddenFields() method returns the HTML needed to display the hidden widgets:

<form action="<?php echo url_for('@some_route') ?>">
  <?php echo $form->renderHiddenFields() ?>
  <ul>
    <?php echo $form['name']->renderRow() ?>
  </ul>
  <input type="submit" />
</form>
 

sfForm now also implements the Iterator interface:

<ul>
  <?php foreach ($form as $field): ?>
    <li><?php echo $field ?></li>
  <?php endforeach; ?>
</ul>
 

That's all for today.

Add a Comment

You must be connected to post a comment.

Comments RSS

  • gravatar
    #1 develop7 said on the 2008/10/08 at 16:33
    Coverage! Yes! At last!
  • gravatar
    #2 Matthias said on the 2008/10/08 at 16:34
    renderUsing() seems to be a bit unflexible because of the restriction of class name schema "sfWidgetFormSchemaFormatterXXX"

    it would be nicer to either be able to pass a full class name or manage a map "list" => "sfWidgetFormSchemaFormatterList" that is possible to by overridden by options or something like that
  • gravatar
    #3 jamiel said on the 2008/10/08 at 16:43
    Could we see some example output of the code coverage? :)
  • gravatar
    #4 Bruce said on the 2008/10/08 at 17:00
    Is there already a release date for 1.2?
  • gravatar
    #5 Ralf M. Metzing said on the 2008/10/08 at 18:36
    I really like this short updates on developmentprocess
    Thank you (for this and whole work on symfony)
  • gravatar
    #6 Markus Staab said on the 2008/10/08 at 18:37
    would be nice to have to have a commandline task which notfies a event.
  • gravatar
    #7 Fabien said on the 2008/10/08 at 22:02
    @jamiel: I have added an image showing the output of the task.
  • gravatar
    #8 Fabien said on the 2008/10/08 at 22:02
    @Markus Staab: I don't understand your wish.
  • gravatar
    #9 Markus Staab said on the 2008/10/09 at 09:54
    @fabien:
    sometimes you want to manually start the programm from a single point (e.g. from a event notification).

    so it would be nice to notify an event from the commandline..

    e.g.
    ./symfony event:notify user.change_authentication <params>