Archive for mai, 2007

un petit batch pour symfony qui change la vie Jeudi, mai 31st, 2007

Il y a quelques temps j’avais essayé d’automatiser un peu le processus de passage du MLD issu de DBDesigner vers l’implémentation SQL proprement dite dans symfony. Depuis j’ai découvert le plugin sfControlPanel et je me suis embourgeoisé …
plus question de taper une ligne de commande dans un terminal!
L’idée c’est toujours de

  • sauver le fichier xml généré par DBDesigner dans data/schema/db.xml
  • sauver le xsl qui permet la transformation sous data/schema/db2propel.xsl
  • et d’adapter le batch/convert_db.php comme suit<?php

<?php
define(’SF_ROOT_DIR’,    realpath(dirname(__FILE__).’/..’));
define(’SF_APP’,         ‘back’);
define(’SF_ENVIRONMENT’, ‘dev’);
define(’SF_DEBUG’,       true);
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.DIRECTORY_SEPARATOR.’config.php’);
$dbPath     = sfConfig::get(’sf_data_dir’).DIRECTORY_SEPARATOR."schema".DIRECTORY_SEPARATOR."db.xml";
$xslPath    = sfConfig::get(’sf_data_dir’).DIRECTORY_SEPARATOR."schema".DIRECTORY_SEPARATOR."dbd2propel.xsl";
$schemaPath = sfConfig::get(’sf_config_dir’).DIRECTORY_SEPARATOR."schema.xml";
$symfonyCmd = "symfony propel-convert-xml";
if (file_exists($dbPath))
{
    $file = fopen($dbPath,"r");
    $xmlstr="";
    while (!feof($file))
    {
      $xmlstr.=fgets($file, 4096);
    }
    fclose($file);
    $xml = new DomDocument; // from /ext/dom
    $xml->loadXML($xmlstr);
    $xsl = new DomDocument;
    $xsl->load($xslPath);
    $proc = new xsltprocessor;
    $proc->importStyleSheet($xsl); // attach the xsl rules
    $xmlstr = $proc->transformToXML($xml);
    $file = fopen($schemaPath,"w");
    fputs($file,$xmlstr);
    fclose($file);
    echo $schemaPath." has been successfully generatedn";
    chdir(SF_ROOT_DIR);
    if(system($symfonyCmd))
    {
      echo $schemaPath." has been successfully converted in YAMLn";
    }
    else
    {
      die("unable to convert ".$schemaPath." in YAMLn");
    }
    if (file_exists($schemaPath))
    {
      unlink($schemaPath);
      echo $schemaPath." has been successfully deleted: you can build!n";
    }
    else{
      die($schemaPath." NOT FOUNDn");
    }
}
else{
  die($dbPath." NOT FOUNDn");
}

Fini le symfony propel-convert-xml et la suppression du schema.xml … une fois ce batch lancé on est paraît pour propel-build-all.
J’ajoute un autre batch dump_data.php qui permet de sauver le contenu de sa base de données en YAML.

<?php
 
define(’SF_ROOT_DIR’,    realpath(dirname(__FILE__).’/..’));
define(’SF_APP’,         ‘back’);
define(’SF_ENVIRONMENT’, ‘dev’);
define(’SF_DEBUG’,       true);
 
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.DIRECTORY_SEPARATOR.’config.php’);
 
// initialize database manager
$databaseManager = new sfDatabaseManager();
$databaseManager->initialize();
$data = new sfPropelData();
$data->dumpData(sfConfig::get(’sf_data_dir’).DIRECTORY_SEPARATOR.’fixtures/dump.yml’);
?>

Si vous avez des soucis avec ce script, ou si vous ne voulez exporter qu’une partie des tables de votre BDD, n’hésitez pas à passer en second paramètre un tableau contenant le nom des objets à sauver (c’est à dire si vous avez une table "article" qui correspond à un objet "Article’, c’est "Article" qu’il faut mettre dans le tableau …).
Ensuite le grand classique (mentionné dans le tuto Askeet) à savoir load_data.php qui permet l’opération inverse (accessoirement il tentera d’importer tout ce qui se termine par ".yml" et qui se trouve dans le répertoire data/fixtures).

<?php
 
define(’SF_ROOT_DIR’,    realpath(dirname(__FILE__).’/..’));
define(’SF_APP’,         ‘back’);
define(’SF_ENVIRONMENT’, ‘dev’);
define(’SF_DEBUG’,       true);
 
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.DIRECTORY_SEPARATOR.’config.php’);
 
// initialize database manager
$databaseManager = new sfDatabaseManager();
$databaseManager->initialize();
$data = new sfPropelData();
$data->loadData(sfConfig::get(’sf_data_dir’).DIRECTORY_SEPARATOR.’fixtures’);
?>

Et sfControlPanel dans tout ça?
Dans la section task vous pouvez lancer ces trois scripts, ainsi que les commandes symfony uselles d’un simple clique …
Que du bonheur!

Quelques plugins symfony Lundi, mai 28th, 2007

Après avoir défini les besoins de la base CMS, il fallait s’intéresser à l’existant. Symfony dispose d’un système de plugins dont j’ai survolé la structure mais qui reste à découvrir en ce qui me concerne.
Voici quelques plugins que j’ai pu tester, en particulier ceux dédiés aux user management.

Un plugin s’installe via pear et créée un répertoire à son nom dans le répertoire plugins du projet. Il a une structure proche de celle du projet mais ne contenant que ce qui le concerne.

Liste des plugins officiels

http://trac.symfony-project.com/trac/wiki/SymfonyPlugins

Explorateur de projet Symfony

http://trac.symfony-project.com/trac/wiki/sfControlPanelPlugin
Permet surtout de consulter le projet de manière structuré, la seule interaction possible réside dans l’exécution de commandes symfony via une page web. Ca peut toujours servir!

user management avec sfGuard

http://trac.symfony-project.com/trac/wiki/sfGuardPlugin
Le plugin est assez simple à installer, et surtout trés riche : Il est extensible quant au modèle du user (pour tout ce qui est renseignement complémentaire, date de naissance, nom, prenom, etc …).
Il est d’ores et déjà prévu pour étendre la classe myUser, et le sign-in signout est prêt à être utilisé!
Seul problème dans mon cas c’est que le permissions ne descendent pas jusqu’à un objet et  se limite à la classe!
http://trac.symfony-project.com/trac/wiki/sfGuardDoctrinePlugin ne répond pas non plus à ce besoin, puisqu’il sagit du même plugin que sfGuard à la couche ORM prêt (Doctrine remplace propel) … il y a surement une bonne raison pour que les deux existent, mais ce n’est pas le problème du moment.

Le schéma de base de sfGuard est donc


Et le schéma auquel j’aspire n’est pas tout à fait celui là, il faudrait un troisième paramètre object à sf_guard_permission, qui permette d’associer une permission à une classe, et un attribut object_id dans sf_guard_user_permission et sf_guard_group_permission qui permette d’associer la permission à un objet précis … La base sfGuard paraît solide, mais je ne sais pas vraiment comment faire ensuite pour coder l’héritage des permissions sur un objet rubrique, qui est finalement ce à quoi je souhaiterai arriver!!

uploader des images avec symfony Lundi, mai 7th, 2007

http://trac.symfony-project.com/trac/wiki/sfThumbnailPlugin
Le plugin s’occupe de tout, et il faut avoir gd activé…
et surtout bien penser à spécifier que le formulaire est multipart

<?=form_tag(’myModule/myAction’,array(’multipart’=>true) ?>

Cette page donne toutes les indications pour y arriver : http://trac.symfony-project.com/trac/browser/doc/branches/1.0/cookbook/upload.txt