Strangebuzz...?

Si vous suivez assidument l'actualité symfony, vous ne pouvez pas rater le post "A week of symfony" de notre ami Javier Equiluz. Il nous concocte donc toute les semaines un condensé du microcosme #symfony. Déjà 258 éditions ! Ça en fait du boulot, encore merci à toi Javier. (Muchas gracias Javier por tu trabajo !). Comme il n'y a pas de raison que ce soit toujours les mêmes qui trinquent, je me suis proposé pour faire la version française de ces articles. Ça ne peut pas faire de mal... trêve de blablas.

Hi symfonians !

Today I released a new plugin; the sfToolsPlugin , it's probably the smallest one I released as it only has one class and 3 main functions. In fact it contains a class I use to copy in every project I am working on. Sometimes with different names... Bored with this, even it's more a snippet than a plugin, I made the symfony1 plugin so I can call it the same way in every project I am working on and install it as a SVN external.

As the name of this plugin is very generic, feel free to send me your contribution requests for something you feel like it could be in it.

• I like and use the sfToolsPlugin

Last week I also released the 1.6.3 version of the sfTCPDFPlugin. It is just of small update to check that it works without problem with the last TCPDF library which is actually at version 5_9_120 (2011-09-22). (Note that the release strategy of this library is very fast with a lot of minor versions). You can check the CHANGELOG here.

PS: There is now more than 100 registered users for this plugin !

See you. COil

Well, 2 years have passed since my post: "Writing symfony plugins is great... maintaining them is better !". I followed my own advices and all my plugins where updated for symfony 1.4 which will be the last major version of the 1.x branch. Now let's see how things evolved since 2 years:

sfDB4toPropelPlugin

• User counts: 11 (+8 users since 12 apr 2009)
• Available for: sf 1.4, 1.3, 1.2
• Users feedbacks: 0
• I like and use the sfDB4toPropelPlugin !
• Want the Symfony2 bundle ? Send me an email !

I must admit I don't use this plugin any more. Because most of people are using Doctrine as it is the recommended ORM for symfony now. But it can be useful for a small project. I didn't had feedbacks about it, it just "do the job" as it should. (It's very stable because it was extensively used for 2 big 1.0 projects)

sfLightboxPlugin

• User counts: 55 (+39 users since 12 apr 2009)
• Available for: sf 1.4, 1.3, 1.2, 1.1, 1.0
• Users feedbacks: 1
• I like and use the sfLightboxPlugin !

It's probably the most useless of my plugin, but I think it is used because it is well documented, very easy to use and available for all symfony major versions.

sfTCPDFPlugin

• User counts: 93 (+84 users since 12 apr 2009)
• Available for: 1.4, 1.3, 1.2
• Users feedbacks: 4
• I like and use the sfTCPDFPlugin !

This plugin had a very nice users boost since its creation, its my most popular plugin. Therefore I suppose that it works quiet well. It allows to avoid dealing with the unfriendly TCPDF constants with a help of a multi-configurations YAML file.

sfTaskLoggerPlugin

• User counts: 8
• Available for: 1.4, 1.3, 1.2, 1.1
• Users feedbacks: 3
• I like and use the sfTaskLoggerPlugin !

Even I think this is the most useful plugin I have done, it is also the most unpopular. It may be due to the large amount of plugins already dealing with tasks, crons, jobs-queues and so on... sfDoctrineCronManagerPlugin, axCronPlugin, sfMCronPlugin, sfJobQueuePlugin, sfGearmanPlugin. I must admit I didn't tried the others as mine fits my needs and the ones of the companies I worked for until now.

sfProjectAnalyserPlugin

• User counts: 27 (+27 users since 7 jan 2011)
• Available for: 1.4, 1.3, 1.2
• Users feedbacks: 7
• I like and use the sfProjectAnalyserPlugin !

This is my last plugin (well "our" plugin as I was not the only to contribute, thanks to all the contributors !) This is probably the most interesting as people where quiet curious about it and we had quiet a lot of positive feedbacks. What is it for ?

The sfProjectAnalyserPlugin allows you to analyse your symfony project, it can raise several coding standards alerts. A YAML configuration file allows you to switch what to analyse and also allows you to parameter threshold for each alert. This plugin can be helpful in mainly two situations:

• You quickly want to check the volumetry and code quality of a symfony project your are going to maintain.
• While developing a project from scratch, as a continuous integration tool, to ensure that as the project grows, you keep on following the symfony coding standards you defined at the very beginning of your project.

Others plugins

• RIP: sfJoomla15BridgePlugin, I gave the leadership of this plugin to another developer (but there is no more activity).
• RIP: sfWorkbenchPlugin: The XML structure of the generated WB schema was quiet hard to parse and I didn't find time to finish its proof of concept. Nevertheless, I would be glad if someone could take over this plugin. It could be very useful and used by many "lazy" developers (Well like me !)

That's 208 "regular" users for all these plugins, which is quiet a good score. I think my "symfony1 plugin developer career" is now over. I hope they have been useful for some of you. Obviously I will continue to maintain theme if big bugs were discovered. But don't except major new features. And now let's publish my first Symfony2 "bundle".

Hi symfonians !

Again, that's quiet a long i didn't post something on symfony. Well i suppose releasing a new is a good occasion for this. Let me introduce the sfTaskLoggerPlugin plugin:

The sfTaskLoggerPlugin plugin allows you to run tasks and store the results. Results are stored in the database in a specific table and also in a log file. Each task has its own log file, witch is stored in a specific directory depending on its namespace and name. (`/log/tasks/:TASK_NAMESPACE/:TASK_NAME`).

The database record stores the following informations:

• Options of the task
• Arguments of the task
• An error code
• Start and end time
• A success flag
• The log file path
• Extra comments (for admin)

It's very useful, I've already used on several project i worked on (from 1.0 to 1.2). You to have a clean and "easy to access" historic (through an admin gen module for example) of all run tasks and their results. How to use it ? Well Very easy !!

• The official README in Markdown synthax (witch is more readable)

Note: The plugin is Doctrine and Propel friendly, it you are using Doctrine, the /lib/config/doctrine/schema.yml will be used whereas using Propel the /lib/config/schema.yml will be used.

Installation

• Install the plugin

       $ symfony plugin:install sfTaskLoggerPlugin

(or download it and unzip in your /plugins directory)

• Clear you cache

       $ symfony cc

Configuration

The plugin comes with a base task class witch is named sfBaseTaskLoggerTask Therefore your tasks must extend this one. Because there is no autoloading at the task level, one must include the base class manually:

   require_once(dirname(FILE). '/sfBaseTaskLoggerTask.class.php');

Note: Of course you will have to change this path depending on where is located your task. For example if it is located in the `/lib/task` folder of your project, the include directive should look like this:

   require_once(dirname(FILE). '/../../plugins/sfTaskLoggerPlugin/lib/task/sfBaseTaskLoggerTask.class.php');

Usage

1 - Create a new class that extends the plugin base class:

<?php
class sfTaskLoggerSampleTask extends sfBaseTaskLoggerTask
?>

2 - Implement the configure() method as you would do with a standard task:

<?php
/**
 * Main task configuration.
 */
protected function configure()
{
  $this->addArguments(array(
    new sfCommandArgument('arg_1', sfCommandArgument::OPTIONAL, 'Test argument 1', 'arg_1_value'),
    new sfCommandArgument('arg_2', sfCommandArgument::OPTIONAL, 'Test argument 2', 'arg_2_value'),
  ));

  $this->addOptions(array(
    new sfCommandOption('env', null, sfCommandOption::PARAMETER_REQUIRED, 'Environment used', 'prod'),
    new sfCommandOption('application', null, sfCommandOption::PARAMETER_REQUIRED, 'Application used', 'frontend'),
  ));

  $this->namespace = 'sf_task_logger';
  $this->name      = 'sample';

  $this->briefDescription = 'This is a sample task !';

  $this->detailedDescription = <<<EOF
The task [sf_task_logger:sample|INFO] doesn't do that much.
It logs itself in the database and in the file system:

  [./symfony sf_task_logger:sample --env=prod|INFO]
EOF;
}
?>

Now there are 2 specific methods to implement:

3 - checkParameters()

<?php

        /**
         * Advanced check of task parameters.
         */
        protected function checkParameters($arguments = array(), $options = array())
        {
          /* // Stupid example test
          if ($this->args['arg_1'] != 'arg_1_value')
          {
            throw new InvalidArgumentException('The value for argument 1 is not valid ! Check the help of the task.');
          }
          */
    
          return true;
        }
?>

Note: This method can be usefull if you have advanced controls to do on task parameters or arguments. Just return `true` if you don't have to use it.

4 - doProcess()

<?php
        /**
         * Main task process.
         */
        protected function doProcess()
        {
          try
          {
            $this->printAndLog(' - This is a log info !!');
            $this->task->setErrorCode(self::ERROR_CODE_SUCCESS);
            $this->setOk();
          }
          catch (Exception $e)
          {
            $this->task->setErrorCode(self::ERROR_CODE_FAILURE);
            $this->setNOk($e);
          }
        }
?>

Note: This is the main method of your task process. `$this->task` is the database object that will be saved. As you can see the `setOk()` and `setNOk` methods allow to set the flag of the record automatically depending on the success or failure of the task.

If you want more control on the task process you can also re-implement the `execute()` method of the base class witch is responsible for calling all others sub functions:

<?php
    /**
     * Global process of the task.
     *
     * @see sfTask
     */
    protected function execute($arguments = array(), $options = array())
    {
      $this->setParameters($arguments, $options);
    
      $this->checkParameters($arguments, $options);
    
      $this->initDatabaseManager();
    
      $this->initLogger();
    
      $this->logStart();
    
      $this->doProcess();
    
      $this->logEnd();
    }
?>

Notes:

The plugin is bundled with a sample task: `/lib/task/sfTaskLoggerSampleTask.class` witch can be run with the following command:

   ./symfony sf_task_logger:sample

TODO

• Include Propel and Doctrine admin generator module

Support

Please report bugs or feature request on this post.

Changelog

• Check the changelog tab of the plugin tab.

See you. COil

PS: I have published this tutorial quiet quickly, please help me by reporting typos and errors.
PS2: The official README file is far more readable
PS3: As always, any contribution will be welcome !