Archives pour août, 2009

De la culture au langage

0
Il y a 2 ans
par Bertrand Zuchuat dans

Symfony ne proposant pas de système pour la gestion du langage selon la culture utilisée, j’ai cherché une solution viable. Je m’explique. Dans mon cas, un utilisateur reçoit une culture « fr_CH » pour permettre un formatage correct sur les nombres. Par contre, dans les urls du site, je désire y mettre uniquement la première partie « fr ». Je vous propose dans ce post de vous livrer ma solution. J’ai pour cela utilisé le système d’Event, qui au passage est vraiment un truc super. Je vous conseille vraiment de découvrir cette petite merveille.

Pour débuter, j’ai rajouté ces quelques lignes dans mon fichier myUser.class.php se trouvant dans le dossier lib de l’application:

class myUser extends sfGuardSecurityUser
{
  public function initialize(sfEventDispatcher $dispatcher, sfStorage $storage, $options = array())
  {
    $dispatcher->connect('user.change_culture', array($this, 'listenToChangeCultureEvent'));
    parent::initialize($dispatcher, $storage, $options);
  }

  public function listenToChangeCultureEvent(sfEvent $event)
  {
    $result = explode('_', $this->culture);
    $this->setLanguage($result[0]);
  }

  public function setLanguage($language)
  {
    $this->language = $language;
  }

  public function getLanguage()
  {
    return $this->language;
  }
}

Comme vous pouvez le voir dans ce code, je me suis connecté à l’event « user.change_culture ». Avec cette fonction, je vais scinder les deux parties de la culture pour ne garder plus que le terme « fr ».

Je voulais ensuite avoir la possibilité d’accéder au paramètre « sf_language » dans mon fichier de routing. J’ai pour cela surchargé la méthode « listenToChangeCultureEvent » de la classe « sfPatternRouting ». J’ai créé un nouveau fichier nommé « mysfPatternRouting.class.php » dans mon dossier lib (toujours dans mon app) avec le code suivant:

class mysfPatternRouting extends sfPatternRouting
{
  public function listenToChangeCultureEvent(sfEvent $event)
  {
    $result = explode('_', $event['culture']);
    $this->setDefaultParameter('sf_language', $result[0]);
    parent::listenToChangeCultureEvent($event);
  }
}

Pour charger ma classe routing, j’ai également modifié le fichier factories.yml en activant cette partie.

all:
  ...
  routing:
    class: mysfPatternRouting
    param:
      load_configuration: true
      suffix:             .
      default_module:     default
      ...

J’ai remplacé le contenu du tag class par « mysfPatternRouting » (Valeur par défaut: sfPatternRouting).

Ensuite, il suffit de vider le cache de symfony pour qu’il charge la nouvelle classe

$ ./symfony cc

Dès maintenant, on aura accès au nouveau paramètre « sf_language » dans notre fichier de routing.yml. Voici un exemple

user_index:
 url:  /:sf_language/user
 param:  { module: user, action: index }
 requirements:
   - sf_language: (?:fr|en|de)

J’espère que cette solution vous sera utile dans vos prochains développements :P

Share

Mettre de la couleur sur votre svn diff

2
Il y a 2 ans
par Bertrand Zuchuat dans ,

Nous allons commencer par installer le package colordiff avec macport (Macintosh).

sudo port install colordiff

Ensuite, nous ajoutons un alias svnd dans le fichier /etc/profile

alias svnd='svn diff --diff-cmd /opt/local/bin/colordiff'

Nous allons recharger la configuration avec la commande suivante:

source /etc/profile

Vous avez également la possibilité de personnaliser la configuration de colordiff. Pour cela, nous allons copier colordiffrc dans notre home:

cp /opt/local/etc/colordiffrc ~/.colordiffrc

Nous pouvons dés maintenant éditer ce fichier et personnaliser les paramètres

Par défaut, nous avons les valeurs suivantes:

plain=off
newtext=blue
oldtext=red
diffstuff=magenta
cvsstuff=green

Nous allons les changer en:

plain=off
newtext=yellow
oldtext=red
diffstuff=magenta
cvsstuff=green

En tapant la commande suivante:

home$ svnd 19-Mastering-Symfony-s-Configuration-Files.txt

Vous devriez voir cela comme résultat final:

colordiff

Share

Passage de votre site en maintenance lors de vos mises à jour

1
Il y a 2 ans
par Bertrand Zuchuat dans

Prérequis: L’activation du plugin sfDoctrineGuardPlugin

Dans le cadre d’un développement, je cherchais à passer à mon application en mode maintenance pour un utilisateur normal mais que le super admin puisse continuer à visualiser les pages du site. La tâche symfony n’est pas satisfaisante dans ce cas car elle verrouille complètement l’accès à celui-ci. Voici donc ma solution:

Premièrement, j’ai activé le paramètre check_lock dans le fichier settings.yml de mon application.

Path: /apps/[NomApp]/config/settings.yml

all:
  .settings:
    check_lock:             on

Pour stocker mon fichier de verrouillage, j’ai créé un dossier « lock » dans le dossier data

mkdir data/lock

Attention: ce dossier doit être en écriture

J’ai ensuite inséré le code suivant dans ProjectConfiguration

Path: /config/ProjectConfiguration.class.php

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    ...
  }

  public function getApplicationLockFile()
  {
    return sfConfig::get('sf_data_dir').DIRECTORY_SEPARATOR.
               'lock'.DIRECTORY_SEPARATOR.$this->getApplication().'.lck';
  }
}

Vient maintenant la partie contrôle de l’accès. Pour cela j’ai créé un filtre que voici

Path: /lib/isApplicationActivatedFilter.class.php

class isApplicationActivatedFilter extends sfFilter
{
  public function execute ($filterChain)
  {
    if ($this->isFirstCall())
    {
      if (sfConfig::get('sf_check_lock'))
      {
        $context = $this->getContext();
        $config = $context->getConfiguration();
        $user = $context->getUser();

        $fileLock = $config->getApplicationLockFile();
        if (file_exists($fileLock) && !$user->isSuperAdmin())
        {
          $files = array(
            sfConfig::get('sf_app_config_dir').'/unavailable.php',
            sfConfig::get('sf_config_dir').'/unavailable.php',
            sfConfig::get('sf_web_dir').'/errors/unavailable.php',
            sfConfig::get('sf_symfony_lib_dir').'/exception/data/unavailable.php',
          );

          foreach ($files as $file)
          {
            if (is_readable($file))
            {
              include $file;
              break;
            }
          }

          die(1);
        }
      }
    }
    $filterChain->execute();
  }
}

Il reste maintenant à charger ce filtre dans notre application

Path: /apps/[NomApp]/config/filters.yml

rendering: ~
security:  ~

# insert your own filters here
isApplicationActivated:
  class:  isApplicationActivatedFilter

cache:     ~
common:    ~
execution: ~

Il faut suffit maintenant de personnaliser votre page de maintenance en créant le fichier unavailable.php dans votre dossier config.

Dès à présent, si vous créer un fichier [NomApp].lck dans le dossier lock, votre application passera en mode maintenance.

Dans cette article, je ne détaille pas la création et la suppression de ce fichier lck. Je vous laisse le soin de le faire avec votre propre gestion.

Pour tester le bon fonctionnement de ce procédé, vous pouvez créer deux comptes dans votre base de données:

  • Compte admin avec le flag is_super_admin: true
  • Compte user sans le flag is_super_admin

Vous vous identifiez avec le compte admin et ensuite vous créer le fichier [NomApp].lck dans votre dossier lock et vous vous rendez compte que vous avez toujours accès au page de votre site. Si vous répétez la chose avec le compte user, vous verrez apparaître la page de maintenance.

J’espère que ce code vous servira dans votre prochain développement.

Bonne découverte.

Share
Haut de page