Partenariat Webpulser - Sensio Labs

Publié par Maxime Druaert Lun 21 avr 2008 14:23:00 GMT

C’est avec succès que Webpulser s’est associé avec l’agence Sensio Labs afin de réaliser un Digg like adapté pour cataloguer les Web Services d’une entreprise du CAC 40.

Pour ceux qui ne connaîtraient pas encore Sensio, sachez que cette agence web est un acteur majeur de l’Open-Source, notamment depuis la création du framework Web Symfony en 2005.

A travers cette réalisation, Webpulser affiche donc sa capacité à mener à bien des projets techniques d’envergure, et à susciter la confiance d’acteurs majeurs de l’open-source.

Publié sous News, Références, Symfony | Mots clés framework, open, proxy, sensiolabs, services, source, Symfony, web, web2.0 | aucun commentaires

Webpulser dans les magazines phpsolutions et LINUX+

Publié par Maxime Druaert Mar 08 avr 2008 15:49:00 GMT

L’actualité des frameworks est riche pour Webpulser en cette année 2008, avec un article sur Symfony publié dans le magazine PHPsolutions ainsi qu’un article sur Ruby on Rails qui paraît ce mois ci dans le magazine Linux+.

• « Don’t Repeat Yourself » : éviter la redondance de code facilite la maintenance, le test, le debuggage et les évolutions.
• « Convention over Configuration »: il est inutile de préciser des détails lorsqu’ils respectent des conventions établies.
  

Afin de faire comprendre à tous, les nombreux intérêts et avantages de Symfony et de RoR, Webpulser a voulu dans ces numéros, vous faire découvrir ou redécouvrir ces frameworks et vous donner l’envie de les essayer et de les adopter.

Créé en 2005, Symfony est un framework MVC open-source écrit en PHP 5. Il est à ce jour le framework PHP le plus abouti et dispose d’une documentation exemplaire ainsi que d’une communauté très active qui s’efforce d’améliorer en permanence la plate-forme de développement.
A travers cet article, Webpulser confirme sa maîtrise de Symfony et nous fait découvrir le large éventail de possibilités offertes par ce framework.

Depuis sa naissance en 2004, Ruby on Rails n’a fait que grandir et commence déjà à atteindre une certaine maturité, qui lui permet d’envisager des projets toujours plus ambitieux. Nombreuses sont les entreprises a avoir déjà franchit le cap même si la France reste en retard par rapport à aux Etats-Unis où RoR à tout de suite été adopté et pèse un poids de plus en plus important dans le monde du développement web.

En effet, les principes de ces frameworks correspondent au besoin grandissant des entreprises de développer des sites dynamiques, évolutifs et surtout avec une productivité record sans pour autant négliger la qualité. Sur ce point, le développement de projets Web autour d’un framework accélère grandement le temps de développement et permet d’atteindre de nouveaux standards de qualité et des objectifs plus élevés qu’auparavant.

Par ces publications, Webpulser démontre une fois de plus son expertise dans les frameworks de dernière génération et les technologies du web 2.0 et affirme son engagement dans la communauté du libre.

Pour aller plus loin:
documentation Symfony en français
workingwithrails

Publié sous News, Ruby & Rails, Symfony | Mots clés Frameworks, on, Rails, Ruby, Symfony | aucun commentaires

ConsoLoc, le nouveau site dédié à la location, est en ligne !

Publié par Aline Bunelle Lun 21 jan 2008 16:59:00 GMT

Après l’occasion, le don, l’échange, le shopping humanitaire, ConsoGlobe a voulu mettre à la disposition des internautes un site dédié à la location entre particuliers. Et c’est chose faite, grâce au savoir faire de l’équipe de Webpulser : ce projet a vu le jour le 9 janvier dernier. Ce site est le petit dernier d’une longue série ayant pour concept la rentabilité économique et écologique !

Une fois de plus, Webpulser nous prouve ses compétences en développant ConsoLoc en Symfony, créant un site dynamique et de qualité.

Vous pouvez donc visitez dès maintenant ConsoLoc

Publié sous News | Mots clés Symfony | aucun commentaires

Security

Publié par Aline Bunelle Jeu 10 jan 2008 18:15:00 GMT

Symfony intégre un système de session et d’utilisateur via la classe sfBasicSecurityUser qui sera détaillé juste après. Cette classe va permettre de définir si un utilisateur est connecté ou s’il possède des droits particuliers appelés « credential ».

default:
  is_secure: off

default:
  is_secure:   on
  credentials: admin

Par défaut, si l’on arrive sur une page pour laquelle l’on ne possède pas de droits, une page Symfony est appelée. Nous pouvons spécifier les modules et actions à associer sur ce genre d’erreur dans le fichier settings.yml et ainsi rediriger sur la page de login par exemple.

Publié sous Symfony | Mots clés Symfony | aucun commentaires

Filters

Publié par Aline Bunelle Jeu 10 jan 2008 18:05:00 GMT

• gestion de cookie;
• tracking;
• redirection spécifique;
• ...

rendering: ~
web_debug: ~
security:  ~

# generally, you will want to insert your own filters here

cache:     ~
common:    ~
flash:     ~
execution: ~

Les filtres sont appelés dans l’ordre de la configuration.

Nous pouvons donc créer en plus nos propres filtres. Généralement ils seront placés au même endroit que le commentaire , mais vous pouvez les mettre où vous voulez.

Par exemple, sur une application sécurisée (voir Security dans le point suivant), nous pouvons créer un filtre que nous appelerons AVANT le filtre security afin de récupérer un cookie qui permettait la connexion d’un utilisateur.

class myFilter extends sfFilter{
    public function execute ($filterChain){
        $sf_user = $this->getContext()->getUser();

        $stats = new Stats();
        $stats->setIp($ip);
        if (isset($_SERVER['HTTP_REFERER']))
            $stats->setReferer($_SERVER['HTTP_REFERER']);
        $stats->setNavigateur($_SERVER['HTTP_USER_AGENT']);
        $stats->setDomain($_SERVER['SERVER_NAME']);
        $stats->save();

        $filterChain->execute();
    }

ATTENTION: l’instruction $filterChain->execute(); est très importante, puisque c’est elle qui va lancer la continuation des filtres à suivre.

Ce système de filtre peut rapidement se révéler indispensable en terme de fonctionnalité et surtout de sécurité.

Publié sous Symfony | Mots clés Symfony | aucun commentaires

Routing

Publié par Aline Bunelle Jeu 10 jan 2008 18:00:00 GMT

Revenons un peu sur ce fichier de configuration que nous avions expliqué très brievement dans un précédent article.

Symfony intègre un système de création d’url. C’est ce qui nous permet de saisir dans les fonctions de Symfony (type link_to) des URI type : MODULE/ACTION; ACTION; ACTION?var=value... Le lien sera généré comme il faut dans tous les cas /MODULE/ACTION/var/value.

# default rules
homepage:
  url:   /
  param: { module: Accueil, action: index }

default_index:
  url:   /:module
  param: { action: index }

default:
  url:   /:module/:action/*

/ : on précise le module et l'action
/:module : on ne précise que l'action
/:module/:action/* : rien a préciser tout est dans l'URL

Nous pouvons y ajouter nos propres règles de routage. elles devront être ajouter avant celle par défaut puisque le fichier est lu de haut en bas.

homepage:
  url:   /jonathan-demoutiez
  param: { module: Accueil, action: presentation }

Publié sous Symfony | Mots clés Symfony | aucun commentaires

Maintenant que nous commençons à connaître symfony

Publié par Aline Bunelle Ven 21 déc 2007 17:06:00 GMT

Nous avons déjà vu pas mal de chose sur symfony, et nous commençons maintenant à nous y habituer.

Allons plus loin dans la configuration

Nous n’avons pour l’instant que la configuration d’une route par défaut, et de notre layout. Mais comme vous vous en doutez il y a beaucoup d’autres choses plus intéressantes que l’on peut configurer.

Factories

• controller // Gestion des actions
• request // Gestion des requêtes du client
• response // Gestion des réponses du client
• user // Gestion du compte utilisateur
• storage // Gestion de la session
• cache // Gestion du cache

all:
  storage:
    class: sfSessionStorage
    param:
      session_name: NOM_COOKIE

Ou de modifier le nom de la classe myUser (créer par défaut) sans grand intérêt.

Si vous redéfinissez une classe elle doit évidemment se situer dans le dossier lib de l’application, ou à la racine si elle s’applique à toutes vos applications.

Settings

Le fichier settings.yml va nous permettre de définir beaucoup de choses. Consultez ce fichier, il contient toutes les posibilités commentées. Ces valeurs commentées sont en réalité les valeurs par défaut affectées à votre application.

Vous pourrez entre autre gérer les modules et actions à appeler en cas de diverses erreurs.

#    validation_error_prefix:    ' ↓ '
#    validation_error_suffix:    '  ↓'

#    validation_error_class:     form_error
#    validation_error_id_prefix: error_for_

#    max_forwards:           5

Chaque paramètre est commenté, je vous laisse donc lire ce fichier.

Publié sous Symfony | Mots clés Symfony | aucun commentaires

Symfony et Validator (suite et fin)

Publié par Aline Bunelle Ven 21 déc 2007 17:03:00 GMT

Les Validator existants

• sfStringValidator
• sfNumberValidator
• sfEmailValidator
• sfUrlValidator
• sfRegexValidator
• sfCompareValidator
• sfFileValidator
• sfCallbackValidator

Vous trouverez des exemples clairs d’utilisation sur cette page

Sécurité

Ce système de validation est très efficace et bien pensé. Il va nous permettre de gérer les erreurs attendues dans nos applications en les séparant du traitement « normal » toujours pour plus de clarté.

Ce point nous offre un atout de sécurité très propre et essentiel pour une bonne application web.

Publié sous Symfony | Mots clés Symfony | aucun commentaires

Symfony et Validator (suite)

Publié par Aline Bunelle Ven 21 déc 2007 17:01:00 GMT

Résumé en image

Validation d’un formulaire

Il est toujours assez lourd de développer un formulaire qui gére les erreurs, réaffiche le formulaire (rempli avec les données qui viennent d’être saisies) avec les erreurs sur les champs erronés.

• Champs non rempli;
• Login existant;
• Les deux mots de passe ne correspondent pas;
• Le mot de passe est trop court;
• Adresse mail invalide;
• ... .

Ce genre de traitement va maintenant être très simple à mettre en place. Pour cela nous écrirons un fichier de configuration yaml portnat le nom de notre action dans le dossier validate.

Syntaxe du fichier de configuration de validation

Nous indiquerons dans ce fichier sur quel type de requête doit fonctionner la validation (POST et/ou GET). Puis, nous indiquerons également si nous activons la repopulation des champs et enfin, la validation de nos champs. Voici un exemple de validation :

methods: [post, get]

fillin:
  enabled: on # Active la repopulation

fields:
  login:
    required: yes
      msg: Le champ login doit être rempli.
    sfPropelUniqueValidator:
      class:        User
      column:       pseudo
      unique_error: Ce login est déjà utilisé, merci d'en choisir un autre.

Ici, le champs login ne doit pas être vide, et ne doit pas déjà exister dans la table user champs pseudo.

Ce système est une surcouche de validation aux fonctions validate, les réactions seront les mêmes en cas de validation ou non.

Développement d’un formulaire

Pour que les messages d’erreurs, et la repopulation (si activée) fonctionnent, il ne nous reste que quelques petites choses à ajouter. Tout d’abord l’utilisation du helper Validation :

<?php use_helper('Validation') ?>

Et nous n’avons plus qu’a géré l’erreur et la repopulation :

<table>
    <tr>
        <td colspan="2" align="center"><?= form_error('login') ?></td>
    </tr>
    <tr>
        <td><?= label_for('login', 'Login :') ?></td>
        <td><?= input_tag('login', $sf_params->get('login')) ?></td>
</table>

La fonction form_error nous permettra de récupérer l’erreur (indiquée dans le fichier de configuration). Rien ne s’affiche s’il n’y a pas d’erreur.

$sf_params->get(‘login’) nous permet de récupérer la valeur saisie (eronnée ou non).

Publié sous Symfony | Mots clés Symfony | 1 commentaire

Symfony et Validator

Publié par Aline Bunelle Ven 21 déc 2007 17:00:00 GMT

Symfony intègre un système de validation très bien pensé qui permet une gestion très facile.

Nous distinguerons la validation des formulaires et le reste, c’est à dire les valeurs venant de l’utilisateur GET & POST, et des données récupérées en base.

La fonction Validate

Dans un controleur, une action est définie via la fonction executeNomAction. Tout comme le mot clé execute, le mot clé validate va nous permettre d’associer une fonction de valiation à notre action. Cette fonction devra retourner true ou false selon le résultat de nos tests.

Remarque :Ne rien retourner dans la fonction Validate revient à retourner False.

Succes & Error

Lorsque la fonction validate retourne true, alors la fonction execute est appelée et continue le fonctionnement normal.

Par contre, si la fonction retourne false , la fonction execute ne sera pas traité et la vue nomActionError sera alors utilisée à défaut de nomActionSuccess dans le cas normal.

La fonction HandleError

Tout comme les mots clés execute et validate, le mot clé handleError peut être lié à notre action. elle sera appelée si elle existe (avant d’utiliser la vue nomActionError) et permettra d’effectuer notre traitement en cas d’erreur.

Si la validation passe, Execute sera la fonction de traitement , sinon il s’agira de handleError.

Validation d’une action

Comme avec execute, les mots clés validate et handleError vont précéder le nom de l’action :

public function executeNomAction(){
    // Traitement si l'action est validée
}
public function validateNomAction(){
    // Validation de l'action. return true || false !
}
public function handleErrorNomAction(){
    // Traitement si l'action n'est pas validée
}

Validation des actions d’un controleur

Il est possible que toutes vos actions doivent vérifier une même validation. Dans ce cas vous pouvez déclarer les fonctions validate et handleError sans suffixe.

Remarque : Ces fonctions (généralisées à un controleur) ne seront appelées que si les fonctions (INDEPENDEMMENT) de validation propre à l’action (validateNomAction et/ou handleErrorNomAction) n’existent pas !

Publié sous Symfony | Mots clés Symfony | aucun commentaires