Technical blog of COil: Symfony, PHP, PEAR & webdev

Strangebuzz...?

» Collapse all «

Tag - tutorial

     

Saturday 28 January 2012

Load fixtures with Symfony2 and YAML files

Hi Symfonians ! :)

I am actually spending a lot of time on testing Symfony2. When building an application, one of the first thing you will have to do is to insert initial data, also called fixtures, so you can use and test your application. There is a documentation on the Symfony website about this subject, it uses the DoctrineFixturesBundle.

It works very well, but I wanted to use YAML files "a la symfony1". So I ended up with this simple solution:

The base Loader class:

First, I create a base Loader class that others entities loaders will extend:


The getModelFixtures() function will load the YAML file corresponding to the current entity, the getModelFile() function will have to be implemented by sub-loaders. The class implements the ContainerAwareInterface so we can access the DIC in the loaders.

The Category loader:


The YAML file:

Both jobs and categories YAML files are almost equal to the Jobeet1 tutorial ones.


The loader class:

The getModelFixtures() function retrieves the fixtures for the Category entity and then you just have to iterate over the array. At each iteration we add a reference to the entity so it can be used in other loaders. (as a foreign key)

The Job loader:


The YAML file:


The loader class:


Same here, but:

  • For each iteration we retrieve the proper category reference we already built in the Category loader (line 30).
  • In Jobeet1 there was a loop directly in the YAML file in order to add lot of job rows, now we can do this loop in our loader: duplicateLastJob().
  • There is also a special case where we force a value for the expiresAt date field that would be overridden by the Job object life-cycle callbacks otherwise.

I think this a good approach as you have the ease of writing YAML without loosing the possibility to handle complex or edge cases with PHP. You can find the code on github.

See you ! COil :)

PS: This tutorial was tested with Symfony Standard Edition 2.0.9.
PS2: If you have a blog post about fixtures, let me know so I can add it below.

Other posts about fixtures:

Monday 6 September 2010

sfTaskLoggerPlugin updated for symfony 1.4

Wow, long time I didn't post, but that don't mean I am no more addicted with symfony. :p All my plugins were updated for symfony1.4. sfTaskLoggerPlugin was the last to be, in fact it was ok in svn but there wasn't the related pear package. Hope you'll give a try because the plugin is quiet unpopular (only 5 subscribers for now) but for sure it is the most useful of all my plugins. It is already used in production for a startup, a big company and for several other projects.

I must mention that there is a very nice review of the plugin on the blog of Tomasz Ducin. (many thanks ! ;) ) where you'll have an interesting feedback on why and how to use the plugin.

I tried to made a clean and quiet exhaustive documentation so you can see if the plugin feeds your needs or not, it's in the README tab.

Here is the change-log since the last PEAR release. (And don't forget the +1 please if you find it somewhat useful ^^):

  • Updated sample and purge tasks
  • Moved "env" and "application" options at the base task level
  • Updated package and README
  • Temporary logs stored into the log application of the project
  • Packages for symfony 1.1, 1.3 and 1.4
  • Plugin has now a YAML to configure if one must save the main output in a file, the database or both
  • Added new field to store the id of the last fully processed record
  • New option that allows to log only if there were thing processed by the task
  • New option to check if the task was already run once in a day
  • New option to check if the task is already running
  • New task to purge failed tasks still flagged as "is_running"
  • Re-factored a bit the code
  • Changed the plugin task namespace to "task-logger" instead of "sf_task_logger"
  • Modified the logSection function
  • Added the logSection method
  • Corrected the log functions
  • Fixed the log messages


See you. COil :)

Sunday 13 September 2009

New 1.2 symfony plugin + tutorial: sfTaskLoggerPlugin

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 !!

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


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 !

Tuesday 9 September 2008

New symfony 1.1 / 1.2 plugin + tutorial : sfDB4toPropelPlugin

1 - sfDB4toPropelPlugin presentation


I've just released a new plugin, it is called sfDB4toPropelPlugin, what is this ? Can it make coffee ? Not yet. ;) Well this one add to symfony a new task: propel:db4-to-propel that allows you to convert a DB4 schema (A DBDesigner 4 schema) into a valid propel schema.yml file. It can handle:

  • I18n tables
  • Foreign keys
  • phpNames of tables
  • Name of propel connection
  • Comments for all fields
  • Name of target schema
  • Lib package name
  • And several other options...


You can read a complete tutorial for this plugin in the full version of this post.
Of course, i'll be glad to have some feedback here, to know what you like / dislike and what could be improved.

See you. COil ;)



Related posts:


PS: Reading the related posts, it seems that i did not use the "last version", so i'll check what can be included in the next version of the plugin.

...

Continue reading...

Thursday 3 April 2008

symfony 1.0 tutorial : Extending the admin generator

[En] Tutorial content:

  • Creating a plugin with a custom admin generator theme
  • Extending the sfActions class
  • Extending the sfPropelAdminGenerator class


Here is little contribution for the symfony code sprint, a symfony tutorial about the admin generator. :) Do you know about it ? I think it's one of my favourite symfony tool, i have developed several applications with symfony and for 75% of them i have made a custom admin generator theme. And as said in the symfony documentation, the admin generator is very very very powerful. ;)
In this tutorial we will see a concrete example on how to extend it to provide a useful new feature. Witch feature ? Well it was one of the things a customer asked me, "I want to be able to delete several rows at a time with check boxes" ... Ahhhhh indeed, it's not a native feature of the admin generator. So.... let's do it... :)

::: Pre-requisite :::


Well i will not explain here how to install symfony as there are lots of tutorials about this on the symfony website and in the wiki. So i will assume you have a clean symfony installation so you can type the symfony command in cli. I used the 1.0.13 version for this tutorial.

::: Creating and setting a new project :::


:: Creating the new project ::


First we will create the new project that we will call tutorial, create a new folder tutorial and launch the init-project task into it.

symfony init-project tutorial

Now let's create the backend application:

symfony init-app backend

As it is always better to have a submain for our application add the following in you apache httpd.conf file and change it with your own path

## COil symfony tutorial n°1 : Extending the admin generator ##

<VirtualHost *:80>
  ServerName dev.tutorial.com
  DocumentRoot "C:\wamp\www\tutorial\web"
  DirectoryIndex index.php
  Alias /sf "c:\wamp\bin\php\php5.2.5\PEAR\data\symfony\web\sf"
  
  <Directory "C:\wamp\www\tutorial\web">
    AllowOverride All
  </Directory>
</VirtualHost>

Add the sub-domain in you hosts file:

127.0.0.1 dev.tutorial.com

Ok, at this point we should have our "Project created!" page. So Let's try to browse http://dev.tutorial.com/backend_dev.php

tuto1-1


:: The database ::


Create a local database, let's call it tutorial again. (same as the project name)
Modify the database settings in the config/database.yml and config/propel.ini file, your database.yml file should look like this:

all:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://root@localhost/tutorial


Now we need a schema, let's take the one of Askeet


Ok now let's try to build the database:

symfony.bat propel-build-all-load backend

Oops, it seems there are some errors. :) As we are quite lazy just delete the password columns and the QuestionTag section of the /datas/fixtures/test_data.yml file.
Let's try again to run the last command. If your are successful you should now have some tables and data in your tutorial database. If not, you probably missed something. ;) At this point we have a valid application with a database, some tables and fixtures. Settings are ok, so can go to the next step.

...

Continue reading...