LibrosWeb.es

You may want to execute a script from the command line (or via a cron table) with access to all the symfony classes and features, for instance to launch batch e-mail jobs or to periodically update your model through a process-intensive calculation. The simple way of doing this is to create a PHP script that reproduces the first steps of a front controller, so that symfony is properly initialized. You can also use the symfony command line system, to take advantage of arguments parsing and automated database initialization.

Initializing symfony just takes a couple lines of PHP code. You can take advantage of all symfony features by creating a PHP file, for instance under the lib/ directory of your project, starting with the lines shown in Listing 16-13.

Listing 16-13 - Sample Batch Script, in lib/myScript.php

<?php
 
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', true);
sfContext::createInstance($configuration);
 
// Remove the following lines if you don't use the database layer
$databaseManager = new sfDatabaseManager($configuration);
$databaseManager->loadConfiguration();
 
// add code here

This strongly looks like the first lines of a front controller (see Chapter 6), because these lines do the same: initialize symfony, parse a project and an application configuration. Note that the ProjectConfiguration::getApplicationConfiguration method expects three parameters:

• an application name
• an environment name
• a boolean, defining if the debug features should be enabled or not

To execute your code, just call the script from the command line:

> php lib/myScript.php

An alternative way of creating custom command line scripts using symfony is to write a symfony task. Just like the cache:clear and the propel:build-model tasks, you can launch your own custom tasks from the command line with php symfony. Custom tasks benefit from the ability to parse command line arguments and options, can embed their own help text, and can extend existing tasks.

A custom task is just a class extending sfBaseTask and located under a lib/task/ directory, either under the project root, or in a plugin directory. Its file name must end with 'Task.class.php'. Listing 16-14 shows a sample custom task.

Listing 16-14 - Sample Task, in lib/task/testHelloTask.class.php

 
class testHelloTask extends sfBaseTask
{
  protected function configure()
  {
    $this->namespace = 'test';
    $this->name = 'hello';
    $this->briefDescription = 'Says hello';
  }
 
  protected function execute()
  {
    // your code here
    $this->log('Hello, world!');
  }
}

The code written in the execute method has access to all the symfony libraries, just like in the previous batch script. The difference is how you call the custom task:

> php symfony test:hello

The task name comes from the protected namespace and name properties (not from the class name, nor from the files name). And since your task is integrated into the symfony command line, it appears in the task list when you just type:

> php symfony

Rather than writing a task skeleton by yourself, you can use the symfony generate:task task. It creates an empty task, and has plenty of customization options. Make sure you check them by calling:

> php symfony help generate:task

Tasks can accept arguments (compulsory parameters, in a predefined order) and options (optional and unordered parameters). Listing 16-15 shows a more complete task, taking advantage of all these features.

Listing 16-15 - More Complete Sample Task, in lib/task/mySecondTask.class.php

class mySecondTask extends sfBaseTask
{
  protected function configure()
  {
    $this->namespace        = 'foo';
    $this->name             = 'mySecondTask';
    $this->briefDescription = 'Does some neat things, with style';
    $this->detailedDescription = <<<EOF
The [foo:mySecondTask|INFO] task manages the process of achieving things for you.
Call it with:
 
  [php symfony foo:mySecondTask frontend|INFO]
 
You can enable verbose output by using the [verbose|COMMENT] option:
 
  [php symfony foo:mySecondTask frontend --verbose=on|INFO]
EOF;
    $this->addArgument('application', sfCommandArgument::REQUIRED, 'The application name');
    $this->addOption('verbose', null, sfCommandOption::PARAMETER_REQUIRED, 'Enables verbose output', false);
  }
 
  protected function execute($arguments = array(), $options = array())
  {
    // add code here
 
  }
}

For more examples on the abilities of the task system, check the source of existing symfony tasks.

If you declare a task with the same name as an existing task, your class overrides the existing task. That means that a plugin can override a symfony task, and that a project can override a plugin task and a symfony task. Add to that the ability to extend an existing task class, and you have a very extensible command line system!