Lancement de Pro d'un Jour

Posted by Maxime Druaert Tue, 08 Apr 2008 16:01:00 GMT

C’est avec une grande fierté que Webpulser s’engage dans l’éducation à travers le lancement du site Pro d’un jour.

Développé en Ruby on Rails, ce site est le fruit d’une initiative civique et bénévole lancée par Webpulser, consoglobe, VB2S, 123Fleurs, Cashstore, Invenio Conseil; et témoigne de la volonté de ces acteurs d’être impliqué dans une démarche pédagogique.


Pro d’un jour est un site qui a pour vocation d’aider les jeunes à s’orienter en rencontrant des professionnels et en passant une journée avec eux. C’est en quelques sorte la bourse nationale de découverte des métiers.

L’idée est venue du constat que beaucoup de jeunes ont du mal à s’orienter et à décider de leur avenir. Les étudiants manquent souvent de contacts pour trouver un stage correspondant à leurs attentes et leur connaissance parfois hasardeuse des métiers ne les aide pas à choisir dans de bonnes conditions.
Par ailleurs, certains secteurs peinent à se faire connaître et à recruter car ils souffrent d’une mauvaise image auprès des étudiants et des jeunes actifs. Or la difficulté à embaucher se renforce avec les départs massifs à la retraite engendrés par le «papy boom».

Les entreprises ont donc toute intérêt à devenir partenaire de Pro d’un jour.
  • pour renforcer leur image auprès de candidats potentiels
  • pour faire découvrir leurs métiers
  • pour attirer candidats, stagiaires et futurs collaborateurs.

De plus, Pro d’un jour est déjà soutenu par plusieurs partenaires; écoles et entreprises qui offrent des journées de découverte aux jeunes, telles que la Banque de Bretagne, AXA, l’armée mais aussi de nombreuses entreprises évoluant dans des secteurs divers et variés (Internet, Bâtiment, Hôtellerie, Droit, Santé…).

Alors surtout, que vous soyez étudiant, professionnel ou à la recherche d’un emploi, n’hésitez pas à vous inscrire sur Pro d’un Jour !

Posted in  | Tags , ,  | no comments

Webpulser dans les magazines phpsolutions et LINUX+

Posted by Maxime Druaert Tue, 08 Apr 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+.

article presse webpulser article presse webpulser


Les frameworks Symfony et Ruby on Rails sont les fruits de 10 années d’expériences dans le développement web au cours desquelles n’ont été conservées que les bonnes pratiques.

Ces 2 frameworks sont très proches dans leur philosophie dont les principes fondamentaux sont:
  • « 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.
Webpulser confirme à travers cet article 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

Posted in  | Tags , , , ,  | no comments

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

Posted by Aline Bunelle Mon, 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

Posted in  | Tags  | no comments

Security

Posted by Aline Bunelle Thu, 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 ».

Nous allons pouvoir ainsi restreindre les droits d’accès à nos applications via le fichier security.yml, par défaut :
default:
  is_secure: off
En passant à « on », l’utilisateur devra être authentifié sur le site (voir la partie d’après). Nous pouvons ajouter des règles sur les « credential » :
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.

Posted in  | Tags  | no comments

Filters

Posted by Aline Bunelle Thu, 10 Jan 2008 18:05:00 GMT

Un système de filtres intégrés à Symfony va nous permettre de pouvoir filtrer toute une application. Ceci est très intéressant pour plusieurs raisons :
  • gestion de cookie;
  • tracking;
  • redirection spécifique;
  • ...
Des filtres sont par défaut utilisés par Symfony via fichier filters.yml :
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.

Vos filtres sont à placer dans le dossier lib de votre application. Par exemple, créons le filtre monFiltre : lib/monFiltre.class.php et traçons les déplacements de l’utilisateur en base :
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.

Remarquez que si vous placez votre code APRES cette instruction, ces dernières seront executées sur le retour des filtres. Quel retour ?? Voici un petit schéma très clair pour vous mieux faire comprendre :
article presse webpulser

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

Posted in  | Tags  | no comments

Routing

Posted by Aline Bunelle Thu, 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.

Pour créer ces liens, Symfony se base sur le fichier de configuration routing.yml
# default rules
homepage:
  url:   /
  param: { module: Accueil, action: index }

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

default:
  url:   /:module/:action/*
Par défaut sont indiqués 3 types de route :
/ : 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.

Ces routes sont donc prises en compte lors de la direction à prendre lorsqu’une requête est effectuée mais aussi lorsque l’on va générer un lien via Symfony, exemple :
homepage:
  url:   /jonathan-demoutiez
  param: { module: Accueil, action: presentation }

Posted in  | Tags  | no comments

Webpulser vous souhaite ses meilleurs voeux !

Posted by Aline Bunelle Tue, 08 Jan 2008 08:03:00 GMT

Webpulser vous souhaite une très bonne année 2008 !

Cette nouvelle année est placée pour nous sous le signe du changement et de la réussite. Toute l’équipe de Webpulser est fière de vous annoncer toutes ces nouveautés:

Par ordre chronologique, nous allons déménager ! ;)

Voici donc notre nouvelle adresse:
14 rue du Coq français
2eme étage
59 100 Roubaix

Nous serons aux côtés de grandes enseignes, telles que ConsoGlobe, Altima, Oxygem, Damart, AD Référencement, La Redoute…

Nous allons aussi élargir nos domaines de compétences en proposant des offres complémentaires au développement de site web:
  • pôle e-marketing pour assurer la promotion de votre site,
  • solution d’outils de gestion e-commerce s’adaptant aux besoins des PME comme des grands comptes,
  • solution d’hébergement fiable et abordable,
  • pôle de découpage xhtml – css indépendant.

Webpulser vous souhaite de concrétiser tous vos projets…

A très bientôt !

Posted in  | Tags , , , , , , , , , ,  | no comments

Maintenant que nous commençons à connaître symfony

Posted by Aline Bunelle Fri, 21 Dec 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

Le fichier factories.yml défini les classes à utiliser pour le fonctionnement des :
  • 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
Il sera rare de venir modifier les classes utilisées par défaut, hormis changer le nom du cookie :
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.

Nous avons vu les validations et l’affichage d’erreurs (dans les formulaires). Vous avez donc remarqué l’affichage de fléches vers le bas encadrant ces messages. Vous pouvez modifier ces caractères de préfixe et suffixe ici également :
#    validation_error_prefix:    ' ↓ '
#    validation_error_suffix:    '  ↓'
Ou encore faire appel à d’autre fonction, ou paramétrer l’id des balises « span » des erreurs :
#    validation_error_class:     form_error
#    validation_error_id_prefix: error_for_
Cette ligne permet de définir le nombre maximum de `forward` que l’application peut suivre avant de déclencher une exception (5 par défaut) :
#    max_forwards:           5

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

Posted in  | Tags  | no comments

Symfony et Validator (suite et fin)

Posted by Aline Bunelle Fri, 21 Dec 2007 17:03:00 GMT

Les Validator existants

Nous avons vu rapidement le validator sfPropelUniqueValidator mais il en existe d’autre :
  • 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.

Posted in  | Tags  | no comments

Symfony et Validator (suite)

Posted by Aline Bunelle Fri, 21 Dec 2007 17:01:00 GMT

Résumé en image

article presse webpulser

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.

Les types d’erreurs les plus courants sont :
  • 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).

Posted in  | Tags  | 1 comment

Older posts: 1 2 3 ... 5