Novius Labs - Cat�gorie : Le Cervo : blog, tutoriaux, recherches

Deux occasions de vous former � l'exp�rience utilisateur avant l'�t�

Antoine Lefeuvre — Mon, 30 Apr 2012 18:10:00 +0200

Nous sommes entr�s dans l'�re post-PC : Internet est aujourd'hui multi-devices et multicanal. L'exp�rience des internautes est loin de se limiter aux seuls sites web. Comment optimiser votre communication pour s'adapter � ce nouveau contexte ?

Pour r�pondre � cette question strat�gique, je vous propose deux dates et deux formules.

(Dans les deux cas, vous aurez l'occasion de comprendre l'énigmatique illustration de ce billet !)

Votre temps est compté

Si le temps vous fait défaut, l'agence Novius Paris et moi vous proposons un atelier formation d'une matinée, mardi 22 mai. Ces quelques heures ensemble seront pour vous l'occasion de comprendre l'expérience utilisateur et ses enjeux et d'en connaitre les règles d'or et les dernières tendances. A travers un cas pratique, vous découvrirez également comment intégrer l'expérience utilisateur à une stratégie de communication digitale.

Inscrivez-vous !

Une formation complète d'une journée

Une journée entière dédiée à l'expérience utilisateur, voilà ce que je vous propose dans le cadre de la Doc School le 6 juin, mais aussi le 10 octobre et le 12 décembre. Nous disposerons du temps nécessaire pour aller au fond des choses et rentrer dans le concret. Comme pour toutes les formations Doc School, l'accent est mis sur la pratique, l'interactivité et le contact avec le terrain. Bref, une formation sur l'expérience utilisateur qui est une vraie expérience de formation !

Inscrivez-vous !

Bookmarklet pour afficher la grille de Foundation

Antoine Lefeuvre — Tue, 03 Apr 2012 14:03:00 +0200

Dans un r�cent article, je vous parlais de in-browser prototyping. Si vous utilisez cette m�thode et plus particuli�rement Foundation, le bookmarklet que j'ai cr�� pourrait vous int�resser.

Installer le bookmarklet.

Le bookmarklet est très simple, il vous permet d'afficher la grille pour un site basé sur le framework open source Foundation. En phase de prototypage, c'est particulièrement pratique, on n'a pas à regarder le code pour vérifier si une div est sur trois ou quatre colonnes. Ca permet aussi de vérifier les alignements.

La grille peut être paramétrée pour s'adapter à tous les graphismes (couleur et opacité des lignes, z-index).

Ce bookmarklet comme Foundation sont sous license MIT. Les sources sont disponibles sur GitHub, n'hésitez pas à le forker.

Voici un exemple avec le site Backup Train réalisé dans le cadre du WIF12 :

Tutoriel FuelPHP #6 : L'ORM, gestion des relations

Victor Albert — Tue, 03 Apr 2012 08:53:00 +0200

Cet article, sans �tre une suite directe, s'inscrit dans la continuit� des tutoriels r�alis�s par Julian et S�bastien. L'objectif de ce tutoriel est d'en apprendre plus sur l'ORM de FuelPHP, afin d'en comprendre les m�canismes principaux. Il s'inscrit dans le cadre de la r�alisation d'une application de gestion d'un catalogue de produits, qui sera motoris�e sous Novius OS (CMS open source bas� sur FuelPHP).

Pour ce tutoriel, on prendra l'exemple plus simple d'un carnet d'adresses.

Mise en place du projet

Sommaire du tutoriel
Développer sous FuelPHP

Préambule

Bien qu'il soit recommandé d'avoir suivi les précédents tutoriels sur FuelPHP, celui-ci est indépendant. Pour ceux qui auraient aimé reprendre leur précédent projet, vous verrez ci-dessous pourquoi il est préférable de commencer un nouveau projet.

Comme pour les tutoriels précédents, on part du principe que vous utilisez MySQL et le logiciel de gestion de bases de données phpMyAdmin.

Création du projet et des premières classes

Pour aller plus vite et pour vous épargner des lignes de codes, on va utiliser la commande oil. On commence donc par créer le projet :

oil create addressbook

N'oubliez pas de créer la base données address_book qui sera associée à votre projet et de configurer votre projet (cf. tutoriels #2 et #3). Ne pas oublier de décommenter la ligne //'Orm', de la liste des packages dans le fichier fuel/app/config/config.php.

On va ensuite ajouter au projet l'élément principal du carnet d'adresse : le contact. On se place donc dans le dossier du projet, puis on exécute les commandes suivantes :

php oil g model contact name:string surname:string tel:string email:string address:text
php oil refine migrate

Vous l'aurez peut-être remarqué, contrairement à la commande utilisée lors du tutoriel #3, celle-ci n'utilise pas le CRUD. Comme expliqué dans ce même tutoriel, la conséquence principale vient du fait que le modèle généré n'étendra pas le Model_Crud, mais le modèle de l'ORM. Étendre le model de l'ORM de FuelPHP est la condition qui va ensuite permettre de gérer des relations. C'est d'ailleurs la raison principale qui fait que le projet précédent ne permettait pas de travailler sur ces questions !

À ce stade je vous conseille d'ouvrir votre éditeur, et vous pouvez commencer par constater que votre modèle étend bien le Model de l'ORM :

<?php
use Orm\Model;

class Model_Contact extends Model
{
    protected static $_properties = array(
        'id',
        'name',
        'surname',
        'tel',
        'email',
        'address',
        'created_at',
        'updated_at',
    );

    protected static $_observers = array(
        'Orm\Observer_CreatedAt' => array(
            'events' => array('before_insert'),
            'mysql_timestamp' => false,
        ),
        'Orm\Observer_UpdatedAt' => array(
            'events' => array('before_save'),
            'mysql_timestamp' => false,
        ),
    );

}

Il ne vous reste qu'à générer les deux autres modèles qui définiront votre application :

php oil g model profile contact_id:int title:string description:text hobbies:string
php oil g model category parent_id:int title:string description:text
php oil refine migrate

Du fait d'avoir utiliser la commande oil generate model plutôt que oil generate scaffold, vous aurez remarqué que les contrôleurs et vues associés n'ont pas été générés. Pour manipuler nos modèles, on utilisera la console de FuelPHP ! Cet outil a le mérite de nous permettre d'effectuer des opérations sur les modèles sans avoir à configurer les vues et les contrôleurs associés. Cela va donc nous permettre de rester concentré sur l'objet de ce tutoriel : l'ORM et les relations.

Création des relations

Afin d'essayer d'être le plus exhaustif possible, on va mettre en place les 3 types principaux de relations:

"many to many"
"has many" (et son complément "belongs to")
"has one" (idem)

Relation "Has One"

Commençons par la relation la plus simple.

Un contact pourra ainsi être associé à un profil. Imaginons que vous souhaitiez étoffer un peu les informations dont vous disposez sur certains contacts. Plutôt que d'avoir un modèle de contacts avec des champs supplémentaires et entraîner la création de contacts incomplets, on ajoute une relation vers un profil qui complètera le contact. On va préciser cette relation au niveau du modèle.

Pour le contact, il suffit d'ajouter l'attribut $_has_one comme ceci :

protected static $_has_one = array(
    'profile' => array(
	'key_from' => 'id',
	'model_to' => 'Model_Profile',
	'key_to' => 'contact_id',
	'cascade_save' => true,
	'cascade_delete' => true,
    )
);

On remarque que, puisque le profil n'a pas d'existence légitime sans un contact, la sauvegarde du contact entraîne nécessairement la sauvegarde du profil. Il en va de même pour la suppression.

En complément, on ajoute sur le modèle du profil l'attribut suivant :

protected static $_belongs_to = array(
    'contact' => array(
	'key_from' => 'contact_id',
	'model_to' => 'Model_Contact',
	'key_to' => 'id',
	'cascade_save' => false,
	'cascade_delete' => false,
    )
);

On remarque que, pour le profil, sa suppression ne doit pas entraîner la suppression du contact et ce pour deux raisons :

On peut envisager que le contact n'ait pas de profil,
Mais surtout le seul moyen de mettre à jour une relation est de supprimer cette relation avant de la réaffecter.

On va maintenant pouvoir commencer à utiliser la console.

Pour bien comprendre les mécanismes de l'ORM, il peut être intéressant d'observer les requêtes réalisées par l'ORM. La démarche pour MySQL sous Ubuntu est expliquée ici.

Dans votre terminal, à la racine de votre projet, exécutez la commande suivante (attention : la console n'est pas complètement stable. En cas d'échec lors de l'exécution de votre commande, il vous faudra la relancer et vous n'aurez plus accès à votre historique, ni à vos variables...) :

oil console

On commence par créer un contact, on lui affecte un profil, avant de valider la création et donc de l'enregistrer en base :

$model = new Model_Contact(array('name'=>'ALBERT', 'surname'=> 'Victor', 'tel'=> '0123456789', 'email'=> 'victor@plop.fr', 'address'=> '0 rue du tutoriel 00000 TUTO'));
$model->profile = new Model_Profile(array('title'=> 'ecommerce', 'description'=> 'works on a project for a few months', 'hobbies'=> 'climbing'));
$model->save();

On peut alors voir les requêtes associées :

INSERT INTO `contacts` (`name`, `surname`, `tel`, `email`, `address`, `created_at`, `updated_at`) VALUES ('ALBERT', 'Victor', '0123456789', 'victor@plop.fr', '0 rue du tutoriel 00000 TUTO', 1333034478, 1333034478)

INSERT INTO `profiles` (`contact_id`, `title`, `description`, `hobbies`, `created_at`, `updated_at`) VALUES (1, 'ecommerce', 'works on a project for a few months', 'climbing', 1333034478, 1333034478)

L'ajout du profil se fait en renseignant la relation. En réalisant l'appel à la méthode save() sur le contact, le cascade_save => true défini avec la relation suffit à sauvegarder le profil dans la base.

La mise à jour de vos données peut ainsi se faire uniquement via le contact :

$model->profile->hobbies = 'cinema';
$model->save()
$model->email = 'albert@plop.fr';
$model->save();

UPDATE `profiles` SET `contact_id` = 1, `title` = 'ecommerce', `description` = 'works on a project for a few months', `hobbies` = 'cinema', `created_at` = 1333034478, `updated_at` = 1333034923 WHERE `profile_id` = 1 LIMIT 1

UPDATE `contacts` SET `name` = 'ALBERT', `surname` = 'Victor', `tel` = '0123456789', `email` = 'albert@plop.fr', `address` = '0 rue du tutoriel 00000 TUTO', `created_at` = 1333034478, `updated_at` = 1333034979 WHERE `contact_id` = 1 LIMIT 1

La suppression est un peu plus compliquée : appeler la méthode delete() sur le profil supprime les données en base, mais ne détruit pas l'objet PHP. Si on appelle la méthode save() par la suite, l'ORM considère que la relation existe toujours et tente de sauvegarder les données. Puisque la relation est théoriquement détruite, le champ contact_id est null et si la base ne le permet pas (comme c'est le cas par défaut) cela génère une erreur. Il faut donc en plus affecter null à la relation ; c'est par ce mécanisme que FuelPHP détruit effectivement l'objet, avant d'appliquer la suppression en base via la méthode save() de votre contact.

$model->profile->delete();
$model->profile = null;
$model->save()

SELECT `t0`.`contact_id` AS `t0_c0`, `t0`.`name` AS `t0_c1`, `t0`.`surname` AS `t0_c2`, `t0`.`tel` AS `t0_c3`, `t0`.`email` AS `t0_c4`, `t0`.`address` AS `t0_c5`, `t0`.`created_at` AS `t0_c6`, `t0`.`updated_at` AS `t0_c7` FROM `contacts` AS `t0` WHERE `t0`.`contact_id` = 1 LIMIT 1
DELETE FROM `profiles` WHERE `profile_id` = 1 LIMIT 1

UPDATE `contacts` SET `name` = 'ALBERT', `surname` = 'Victor', `tel` = '0123456789', `email` = 'albert@plop.fr', `address` = '0 rue du tutoriel 00000 TUTO', `created_at` = 1333035504, `updated_at` = 1333036579 WHERE `contact_id` = 1 LIMIT 1
SELECT `t0`.`profile_id` AS `t0_c0`, `t0`.`contact_id` AS `t0_c1`, `t0`.`title` AS `t0_c2`, `t0`.`description` AS `t0_c3`, `t0`.`hobbies` AS `t0_c4`, `t0`.`created_at` AS `t0_c5`, `t0`.`updated_at` AS `t0_c6` FROM `profiles` AS `t0` WHERE `t0`.`profile_id` = '1' LIMIT 1

Relation "Has Many"

On va maintenant travailler avec les catégories. Envisageons l'utilisation suivante : chaque contact pourra par la suite être associé à une ou plusieurs catégories. Ces catégories sont hiérarchisées : on peut envisager une catégorie "Travail" et des sous-catégories "R&D", "Marketing". On pourrait classer ses contacts de manière suffisamment précise pour pouvoir :

les trouver rapidement
les filtrer rapidement
retrouver le contexte dans lequel on les a connus

Ce type de relation peut donc être mis en place avec la relation "Has Many". On ajoute donc les deux propriétés suivantes au modèle de la catégorie :

    protected static $_has_many = array(
        'variants' => array(
            'key_from' => 'id',
            'model_to' => 'Model_Category',
            'key_to' => 'parent_id',
            'cascade_save' => true,
            'cascade_delete' => true,
        )
    );

    protected static $_belongs_to = array(
        'parent' => array(
            'key_from' => 'parent_id',
            'model_to' => 'Model_Category',
            'key_to' => 'id',
            'cascade_save' => true,
            'cascade_delete' => false,
        )
    );

On remarque que le cascade_delete est true dans le sens "parent -> enfant", et false dans le "sens enfant -> parent". Cela se comprend facilement : "Travail" reste légitime si on décide de supprimer "Marketing" alors que si on décide de supprimer "Travail", c'est qu'on ne souhaite plus associer de contacts au "Travail" et à toutes ses déclinaisons.

On va commencer par préciser que le champ parent_id peut être null. Plusieurs solutions sont possibles :

l'indiquer directement dans la base via votre gestionnaire de base de données ;
ou modifier la fonction up() de la migration correspondant à la création des catégories :

public function up()
	{
		\DBUtil::create_table('categories', array(
			'id' => array('constraint' => 11, 'type' => 'int', 'auto_increment' => true),
            'parent_id' => array('constraint' => 11, 'type' => 'int', 'null' => true),
			'title' => array('constraint' => 255, 'type' => 'varchar'),
			'description' => array('type' => 'text'),
			'created_at' => array('constraint' => 11, 'type' => 'int'),
			'updated_at' => array('constraint' => 11, 'type' => 'int'),
		), array('id'));
	}

oil refine migrate:down
oil refine migrate:up

On va ensuite vérifier le bon comportement des catégories et des déclinaisons :

$parent = Model_Category::forge(array('title' => 'Friends', 'description' => 'People I like to see at anytime'));
$parent->save();
$parent->variants[] = Model_Category::forge(array('title' => 'School', 'description' => 'People I met when I was a student'));
$parent->variants[] = Model_Category::forge(array('title' => 'Childhood', 'description' => 'People I know since I was a kid'));
$parent->save();

INSERT INTO `categories` (`parent_id`, `title`, `description`, `created_at`, `updated_at`) VALUES (null, 'Friends', 'People I like to see at anytime', 1333354737, 1333354737)

UPDATE `categories` SET `parent_id` = null, `title` = 'Friends', `description` = 'People I like to see at anytime', `created_at` = 1333354737, `updated_at` = 1333354791 WHERE `id` = 1 LIMIT 1
INSERT INTO `categories` (`parent_id`, `title`, `description`, `created_at`, `updated_at`) VALUES (1, 'School', 'People I met when I was a student', 1333354791, 1333354791)
INSERT INTO `categories` (`parent_id`, `title`, `description`, `created_at`, `updated_at`) VALUES (1, 'Childhood', 'People I know since I was a kid', 1333354791, 1333354791)

La clé du tableau qui gère les relations correspond à l'identifiant de la catégorie associée :

>>> $parent->variants
array (
  2 => 
  Model_Category::__set_state(array(
     '_is_new' => false,
     '_frozen' => false,
     '_data' => 
    array (
      'title' => 'School',
      'description' => 'People I met when I was a student',
      'parent_id' => 1,
      'updated_at' => 1333358505,
      'created_at' => 1333358505,
      'id' => 2,
    ),
     '_original' => 
    array (
      'title' => 'School',
      'description' => 'People I met when I was a student',
      'parent_id' => 1,
      'updated_at' => 1333358505,
      'created_at' => 1333358505,
      'id' => 2,
    ),
     '_data_relations' => 
    array (
    ),
     '_original_relations' => 
    array (
    ),
     '_view' => NULL,
     '_iterable' => 
    array (
    ),
  )),
  3 => 
  Model_Category::__set_state(array(
     '_is_new' => false,
     '_frozen' => false,
     '_data' => 
    array (
      'title' => 'Childhood',
      'description' => 'People I know since I was a kid',
      'parent_id' => 1,
      'updated_at' => 1333358505,
      'created_at' => 1333358505,
      'id' => 3,
    ),
     '_original' => 
    array (
      'title' => 'Childhood',
      'description' => 'People I know since I was a kid',
      'parent_id' => 1,
      'updated_at' => 1333358505,
      'created_at' => 1333358505,
      'id' => 3,
    ),
     '_data_relations' => 
    array (
    ),
     '_original_relations' => 
    array (
    ),
     '_view' => NULL,
     '_iterable' => 
    array (
    ),
  )),
)

On peut ensuite modifier indifféremment toutes les catégories, directement ou via la catégorie parente :

$parent->variants[2]->description = 'Those I met when I was a student';
$parent->save();
$child = Model_Category::find('first', array('where' => array(array('title', 'Childhood'))));
$child->description = 'Those I know since I was a child';
$child->save();
$parent->variants

UPDATE `categories` SET `parent_id` = null, `title` = 'Friends', `description` = 'People I like to see at anytime', `created_at` = 1333358474, `updated_at` = 1333358676 WHERE `id` = 1 LIMIT 1
UPDATE `categories` SET `parent_id` = 1, `title` = 'School', `description` = 'Those I met when I was a student', `created_at` = 1333358505, `updated_at` = 1333358676 WHERE `id` = 2 LIMIT 1

UPDATE `categories` SET `parent_id` = '1', `title` = 'Childhood', `description` = 'Those I know since I was a child', `created_at` = '1333358505', `updated_at` = 1333358954 WHERE `id` = '3' LIMIT 1

Pour limiter le nombre de requêtes, il est donc préférable d'appeler la méthode save() directement sur l'objet modifié, mais il peut être bien pratique d'utiliser la sauvegarde récursive.

Note : on peut aussi appeler la méthode save() sur la relation en passant par la catégorie parente :

$parent->variants[3]->description = 'Those I have known since my childhood';
$parent->variants[3]->save();

La suppression des catégories se fait selon le comportement prévu, et comme pour la relation "has one", il faut supprimer l'objet dans la base si on ne souhaite pas la réaffecter ensuite :

Remarque : La fonction unset est actuellement mal supportée par la console, pour rectifier le problème, on ajoute false; avant l'appel.

$parent->variants[3]->delete();
false; unset($parent->variants[3]);
$parent->save();

Vous pouvez constater que votre table ne contient plus que la catégorie principale "Friends" et la catégorie secondaire "School". En supprimant la catégorie principale, la catégorie secondaire sera également supprimée :

$parent->delete();
Model_Category::find('all')

SELECT `t0`.`id` AS `t0_c0`, `t0`.`parent_id` AS `t0_c1`, `t0`.`title` AS `t0_c2`, `t0`.`description` AS `t0_c3`, `t0`.`created_at` AS `t0_c4`, `t0`.`updated_at` AS `t0_c5` FROM `categories` AS `t0` WHERE `t0`.`parent_id` = '1'
DELETE FROM `categories` WHERE `id` = '1' LIMIT 1
SELECT `t0`.`id` AS `t0_c0`, `t0`.`parent_id` AS `t0_c1`, `t0`.`title` AS `t0_c2`, `t0`.`description` AS `t0_c3`, `t0`.`created_at` AS `t0_c4`, `t0`.`updated_at` AS `t0_c5` FROM `categories` AS `t0` WHERE `t0`.`id` IS null LIMIT 1
SELECT `t0`.`id` AS `t0_c0`, `t0`.`parent_id` AS `t0_c1`, `t0`.`title` AS `t0_c2`, `t0`.`description` AS `t0_c3`, `t0`.`created_at` AS `t0_c4`, `t0`.`updated_at` AS `t0_c5` FROM `categories` AS `t0` WHERE `t0`.`parent_id` = '2'
DELETE FROM `categories` WHERE `id` = '2' LIMIT 1

Relation "Many to Many"

Dernière relation à mettre en place : affecter une à plusieurs catégories à un ou plusieurs contacts.

Pour enregistrer la relation, il faut une table dédiée :

Vous pouvez l'ajouter via votre gestionnaire de base de données ;
Ou générer la migration suivante et effectuer la commande oil refine migrate. Le contenu de la migration est donné ci-dessous:

php oil g migration create_contacts_categories

<?php

namespace Fuel\Migrations;

class Create_contacts_categories
{
    public function up()
    {
        \DBUtil::create_table('contacts_categories', array(
            'contact_id' => array('constraint' => 11, 'type' => 'int'),
            'category_id' => array('constraint' => 11, 'type' => 'int'),
        ), array('contact_id', 'category_id'));
    }

    public function down()
    {
        \DBUtil::drop_table('contacts_categories');
    }
}

Il vous faut ensuite écrire la relation sur vos modèles. Pour le contact :

    protected static $_many_many = array(
        'categories' => array(
            'key_from' => 'id',
            'key_through_from' => 'contact_id',
            'table_through' => 'contacts_categories',
            'key_through_to' => 'category_id',
            'model_to' => 'Model_Category',
            'key_to' => 'id',
            'cascade_save' => false,
            'cascade_delete' => false,
        )
    );

Pour la catégorie :

    protected static $_many_many = array(
        'contacts' => array(
            'key_from' => 'id',
            'key_through_from' => 'category_id',
            'table_through' => 'contacts_categories',
            'key_through_to' => 'contact_id',
            'model_to' => 'Model_Contact',
            'key_to' => 'id',
            'cascade_save' => true,
            'cascade_delete' => false,
        )
    );

Vous pouvez maintenant créer vos contacts et catégories et tester les relations :

$colleague = Model_Contact::forge(array('name' => 'LEFEUVRE', 'surname' => 'Antoine', 'tel' => '0123456789', 'email' => 'lefeuvre@plop.fr', 'address'=> '0 rue du tutoriel 00000 TUTO'));
$friend = Model_Contact::forge(array('name' => 'DUPONT', 'surname' => 'Jean', 'tel' => '0987654321', 'email' => 'jean@plop.fr', 'address' => '0 rue de la paix 00000 TUTO'));
$colleague->save();
$friend->save();
$category = Model_Category::forge(array('title' => 'Friends', 'description' => 'People I like to see at anytime'));
$category->save();
$work = Model_Category::forge(array('title' => 'Work', 'description' => 'People I met at work'));
$work->save();
$work->variants[] = Model_Category::forge(array('title' => 'Novius', 'description' => 'People I met at Novius'));
$work->variants[] = Model_Category::forge(array('title' => 'Former', 'description' => 'People I met when working in a former enterprise'));
$work->save();

$novius = Model_Category::find('first', array('where' => array(array('title', 'Novius'))));
$colleague->categories[] = $novius;
$colleague->save();
$friend->categories[] = Model_Category::find('first', array('where' => array(array('title', 'Friends'))));
$friend->categories[] = Model_Category::find('first', array('where' => array(array('title', 'Former'))));;
$friend->save();
Model_Contact::find('all')

Exemple : supprimer la catégorie principale et vérifier qu'elle n'est plus affectée aux contacts (on la retrouve sur les _original_relations mais a disparu des _data_relations) :

$work->delete();
Model_Contact::find('all')

Bilan

Vous êtes maintenant capable de mettre en place les trois types de relations principaux. Il ne vous reste qu'à les configurer selon vos besoins, et vous pourrez également tester les nombreuses possibilités associées à la fonction find (expliquées succintement sur cette page).

Pour info : le schéma illustrant ce tutoriel provient provient de cette page.

WIF12 : exp�rience utilisateur, exp�rience de designer

Antoine Lefeuvre — Thu, 29 Mar 2012 17:00:00 +0200

Le 16 mars, se sont d�roul�es les pr�s�lections du concours du Festival international du design interactif de Limoges, mieux connu sous le nom de WIF (voire #wif12 pour les tweetos !). 24 heures chrono pour r�aliser, en �quipe de quatre maximum, un prototype d'interface ou service innovant. Cette ann�e, le sujet de la comp�tition �tait "Design interactif et d�veloppement durable".

Une �quipe de novusiens faisait partie des 200 �quipes qui, � travers le monde, ont pris part au challenge. On a beaucoup parl� exp�rience utilisateur et, pourtant, j'en retiens une exp�rience de designer.

La team Novius était constituée d'un graphiste (Frédéric Jacquemoud), deux développeurs (Julien Guyomard et Sébastien Drouyer) et d'un UX designer (votre serviteur). Notre réalisation porte le nom de Backup Train. Il s'agit d'un prototype de service sur smartphone et mur intelligent (type tweetwall). Son objectif est d'aider les usagers des transports publics à trouver facilement et rapidement une solution de repli, en cas de perturbation du trafic.

Je vous laisse découvrir notre projet. Je vais plutôt vous parler de sa réalisation en marche forcée et des enseignements que j'en tire.

In-browser prototyping

En plus de dix années de web design, j'ai utilisé de nombreuses techniques de prototypage : maquettes ou wireframes cliquables (avec de bonnes vieilles images mappées ou, plus récemment, InVision), logiciels dédiés (Balsamiq, Axure), vidéos de démonstration, Flash, etc. Depuis plusieurs mois, je m'intéresse surtout à ce que ZURB appelle le in-browser prototyping.

En quoi consiste cette méthode ? Il s'agit d'attaquer le code le plus tôt possible, sans pour autant perdre en rapidité d'exécution ce qui est essentiel pour le prototypage. Concrètement, on utilise un inspecteur de code (Firebug) et un boilerplate comme Foundation, Twitter Bootstrap ou encore HTML KickStart. Ce sont de vrais kits à prototype. Ils fournissent des styles de base, une grille typographique, des éléments d'UI (menus, formulaires), des plugins jQuery (diaporamas, fenêtres modales), j'en passe.

Bref, la seule installation à faire est celle du boilerplate, on dispose alors de tous les éléments nécessaires pour prototyper. Cerise sur le gâteau, ces boilerplates sont tous à l'heure du multi-devices, contrairement à la plupart des autres techniques de prototypage. Ils sont ainsi en adéquation avec des méthodes future-friendly, comme le design universel et Mobile First.

Pour le WIF, là où le in-browser prototyping s'est révélé décisif, c'est qu'il n'y a pas de rupture entre le prototype et le produit final. Il n'y a pas à intégrer des maquettes, le prototype évolue naturellement en un site ou application, au fur et à mesure qu'on l'affine, qu'on rentre dans le détail. C'est ce qui s'est passé pour le site Backup Train : le site est le prototype. Nous aurions difficilement pu nous permettre de réaliser un site plus une application mobile en 24 heures, si nous avions choisi une autre technique de prototypage.

Réflechir longuement, produire vite

La question s'est tout de suite posée : doit-on se fixer des deadlines intermédiaires, étape par étape, pour tenir LA deadline, celle des 24 heures ? Nous sommes tombés d'accord, pas de limite à la réflexion. Ce n'était pas pour moi une décision évidente. J'étais tenté de dire : imposons une deadline, de la contrainte naîtra l'idée. Je me suis rendu compte a posteriori que nous avions fait le bon choix. Ou plutôt les bons choix, car en décidant de prendre notre temps pour réfléchir, nous actions que la production, elle, aurait à être rapide.

Backup Train n'aurait pas vu le jour si nous n'avions dédié que deux heures à la réflexion. Le concept nous est, en effet, venu relativement tardivement. Or, il s'agit de la fondation du projet, sur laquelle il est difficile de revenir après coup. Autant donc partir confiant, ce que nous avons fait.

Produire vite a aussi ses vertus. On se concentre sur l'essentiel, on touche plus rapidement au concret et, le diable étant dans les détails, cela révèle des zones d'ombre qu'il était impossible d'identifier lors de la réflexion initiale. Cela permet aussi de garder l'idée au chaud, que le développement ne devienne pas une fin en soi. Le in-browser prototyping s'inscrit parfaitement dans cette logique.

L'expérience d'un concours est-elle transposable à un cas réel, en agence notamment ? Au moment d'établir un rétro-planning, peut-on raisonnablement se dire : prenons tout le temps de la réflexion, on produira plus vite (et sans doute moins) ? Cela semble utopique, pourtant, l'idée est séduisante car elle impose des contraintes là où elles sont bénéfiques. Sur la production, pour séparer l'essentiel du superflu, plutôt que sur la réflexion, où le risque est d'aboutir à une idée mort-née.

Inter-disciplinarité obligatoire

Mon meilleur souvenir du challenge est le travail en commun et sans frontières. Bien entendu, nous avons tous nos spécialités, mais nous avons fourni un vrai travail d'équipe, décloisonné. Habituellement, nous travaillons par phase : la conception, puis le graphisme, puis le développement. Evidemment, les méthodes agiles permettent de casser ce cycle en V mais, cela n'empêche, les phases de travail simultanées entre les différents corps de métier ne sont pas si fréquentes que ça.

Pour le WIF, nous avons tous suivi le projet de A à Z. De l'idée à la mise en ligne. On ne demandait pas l'avis d'un technicien pendant la phase de conception ou celui d'un graphiste lors de la finalisation. Il s'agissait de l'avis d'un équipier, peu importe sa spécialité et peu importe la phase du projet.

C'est le rush qui nous a imposé cette inter-disciplinarité et c'est bien malheureux. Au quotidien, malgré toutes les velléités d'agilité et de transversalité, nous cloisonnons, souvent inconsciemment. Pourtant, rien de tel que de mettre la main à la pâte, au code pour un designer, au design pour un technicien, pour mieux comprendre l'autre et arriver, collectivement, à une solution plus intelligente.

Et maintenant ?

Les réalisations des différentes équipes ont été publiées il y a peu. Je n'ai pas eu encore l'occasion de tout regarder (je doute l'avoir un jour), mais j'ai déjà vu d'excellents projets. La partie s'annonce serrée.

Les résultats seront connus le 2 avril et je croise les doigts pour que la team Novius soit de la finale à Limoges. L'occasion de renouveler cette expérience de designer, au service de l'expérience utilisateur.

Tutoriel FuelPHP #5 : la cheat sheet

Antoine Lefeuvre — Thu, 16 Feb 2012 17:03:00 +0100

Gr�ce aux quatre premiers volets de notre tutoriel FuelPHP, vous devriez maintenant �tre lanc�(e) avec ce nouveau framework. Maintenant, pour vous aider dans vos d�veloppements, nous avons r�alis� une cheat sheet. Nous en avions nous-m�mes bien besoin pour le projet Novius OS.

Sommaire du tutoriel
Développer sous FuelPHP

Novius OS est un nouveau CMS open source motorisé par FuelPHP (mais aussi par HTML5, Wijmo et d'autres). L'équipe de développement utilise donc le framework tous les jours ou presque. Difficile dans ces conditions de se passer d'une cheat sheet. Malheureusement, aucune n'était disponible... jusqu'à aujourd'hui. Voici la première cheat sheet FuelPHP par l'équipe de Novius OS :

La cheat sheet est disponible sous plusieurs formes : site web, mobile (scannez le QR code ci-dessus) et PDF.

A noter qu'elle est générée directement à partir de la documentation de FuelPHP. Le code de génération ainsi que l'UI sont disponibles sur un dépôt GitHub dédié. N'hésitez donc pas à contribuer à l'amélioration de cette cheat sheet. En effet, elle a beau être belle, elle n'est pas parfaite pour autant ! Par exemple, seul le core est documentée, ajouter les packages serait une bonne idée.

Bon(s) développement(s) à l'aide de la cheat sheet et à très vite pour d'autres tutoriaux FuelPHP.

Tutoriel FuelPHP #4 : une application type

S�bastien Drouyer — Mon, 09 Jan 2012 17:54:00 +0100

Cet article s'inscrit dans la suite du pr�c�dent article Cr�ation d'un projet avec FuelPHP. Le but de cet article n'est pas d'�tre complet, mais de vous donner les bases pour d�velopper une application. L'exemple que nous allons �tudier est un agenda.

Conception de l'agenda

Sommaire du tutoriel
Développer sous FuelPHP

1. Structure des pages

Commençons par la structure des pages, très classique (voir rétro) pour ce type d’application.

En partie supérieure, le header, qui indique que nous nous trouvons dans l’agenda.
Juste en dessous, un menu, nous indiquant dans quelle catégorie nous nous trouvons.
En dessous et à gauche, la liste. Lorsqu’on se trouve dans la catégorie Notes, il s’agit de la liste des notes. Quand on se trouve dans la catégorie Adresses et numéros, il s’agit de la liste des adresses.
À droite la vue : quand un utilisateur sélectionne un élément dans la liste, il peut alors le visualiser et effectuer les actions de base dans cette partie.
Tout en bas, le footer, reprenant le footer de FuelPHP.

Le header, le menu et le footer peuvent se présenter directement dans le template.
Par contre, la liste et la vue seront générées dans des vues différentes.

2. Modèle de données

Nous avons déjà créé les notes qui contiennent chacune un titre et une description.
Nous rajouterons les personnes (catégorie adresses et numéros), qui contiennent un nom, un prénom, un numéro de téléphone, une adresse et des informations additionnelles.

Installation de fichiers annexes

Nous aurons besoin du framework jQuery, de fichiers CSS et d’images pour que le style soit déjà en place. Ces ajouts cosmétiques (si on veut :)) ne sont pas l’objet de ce tutoriel (heureusement !). Vous pouvez trouver la source finale ici. Contentez vous de remplacer votre dossier public/assets par celui de la source finale.

À noter que les fichiers CSS ont été générés avec le framework Compass. Encore une fois, ce n'est pas l’objet de ce tutoriel.

Implémentation

1. Implémentation du template

Avant de modifier les vues ou les actions, on va modifier le template qui représente la structure de la page.

Ouvrez le fichier fuel/app/views/template.php, on y insérera le code suivant :

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title><?php echo $title; ?></title>
    <?php echo Asset::css('screen.css'); ?>
    <?php echo Asset::css('print.css'); ?>
    <!--[if IE]>
    <?php echo Asset::css('ie.css'); ?>
    <![endif]-->
    <?php echo Asset::css('agenda.css'); ?>
    <?php echo Asset::js('jquery-1.7.1.min.js'); ?>
</head>
<body>
<div id="main">
    <div id="header">
        Agenda
    </div>
    <?php echo render('_menu'); ?>
    <div id="content">
        <?php if (Session::get_flash('error')): ?>
        <div class="error"><?php echo implode('<br/>', (array) Session::get_flash('error')); ?></div>
        <?php endif; ?>
        <?php if (Session::get_flash('success')): ?>
        <div class="success"><?php echo implode('<br/>', (array) Session::get_flash('success')); ?></div>
        <?php endif; ?>
            <div class="inside">
                <?php echo $content; ?>
            </div>
    </div>
    <div id="footer">
        <a href="http://fuelphp.com">Fuel</a> is released under the MIT license.<br />Page rendered in {exec_time}s using {mem_usage}mb of memory.
    </div>
</div>
</body>
</html>

On ajoute les fichiers CSS et JS via la classe Asset (respectivement Asset::css et Asset::js). Par exemple :

<?php echo Asset::css('screen.css'); ?>

générera le code suivant en HTML :

<link rel="stylesheet" type="text/css" href="http://localhost/mon_site_fuel/public/assets/css/screen.css?1322929428" />

Il s'agit encore d'helpers qui simplifient la tâche de l'utilisateur. En plus de limiter le nombre de caractères à écrire, vous remarquerez, à la fin de l'URL du fichier CSS, un nombre obligeant le navigateur à recharger le fichier s'il a été modifié depuis la dernière visite (sans passer par le cache). Ces deux fonctions ont aussi d'autres paramètres, je vous invite à consulter la documentation associée.

Sinon, vous pouvez facilement séparer les différentes parties qu'on avait définies lors de l'introduction. Le header et le footer sont de simples DIV. Le menu est affiché grâce au partial _menu. Dans le DIV content, on constate que, pour le moment, aucune différentiation n'existe entre la zone "Liste" et la zone "Vue". On y reviendra un peu plus tard dans cet article.

2. Implémentation du menu

Maintenant que nous faisons appel au partial _menu, il faut bien implémenter le fichier. Créez le fichier fuel/app/views/_menu.php et ouvrez-le avec votre éditeur préféré.

<div id="menu">
    <?php echo Html::anchor('notes/index', 'Notes', array('class' => 'item '.(\Request::active()->controller == 'Controller_Notes' ? 'active' : ''))) ?>
    <?php echo Html::anchor('people/index', 'Adresses et num�ros', array('class' => 'item '.(\Request::active()->controller == 'Controller_People' ? 'active' : ''))) ?>
</div>

On peut voir qu'il s'agit avant tout d'un ensemble de liens. Vous connaissez déjà la fonction Html::anchor qui permet de générer des liens. On ajoute par défaut à ces liens la classe item, puis, conditionnellement, la classe active permettant de surligner le menu actuel. Jetons un coup d'œil à la première condition :

\Request::active()->controller == '\Controller_Notes' ? 'active' : ''

La fonction \Request::active() permet de récupérer les information sur la requête de l'utilisateur. Notamment :

\Request::active()->controller

qui permet de connaître le contrôleur par lequel l'utilisateur est passé, et

\Request::active()->action

qui permet de connaître l'action appelée. Je vous invite à consulter la documentation associée.

Connaître le contrôleur et l'action qui ont été appelés peut être pratique dans certains cas dans les vues, mais c'est plus souvent le cas dans les contrôleurs. Dans le cas du menu, cela nous évite d'envoyer un paramètre au niveau de chaque contrôleur pour indiquer le menu sélectionné.

3. Généralisation du fonctionnement des contrôleurs

Dans l'article précédent, nous avons eu l'occasion de remarquer un certain nombre de répétitions dans les contrôleurs générés par Scaffold :

<?php
class Controller_Notes extends Controller_Template 
{

	public function action_index()
	{
		//...
		$this->template->title = "Mes notes";
		$this->template->content = View::forge('notes/index', $data);
	}

	public function action_view($id = null)
	{
		//...
		$this->template->title = "Note";
		$this->template->content = View::forge('notes/view', $data);
	}

	public function action_create($id = null)
	{
		//...
		$this->template->title = "Notes";
		$this->template->content = View::forge('notes/create');
	}

	public function action_edit($id = null)
	{
		//...
		$this->template->title = "Notes";
		$this->template->content = View::forge('notes/edit');
	}

	//...


}

Ces répétions peuvent sembler un peu excessives, notamment au niveau de l'attribut $this->template->content, où l'on charge tout le temps le fichier vue. En effet, lorsqu'on appelle l'action index, on affiche notes/index, quand on appelle l'action view on affiche notes/view et, de manière générale, lorsqu'on appelle l'action NOM_ACTION du contrôleur NOM_CONTROLEUR, on s'attend à afficher NOM_CONTROLEUR/NOM_ACTION (c'est du moins le fonctionnement dans plusieurs frameworks, comme Rails ou Symfony).

Il est, cependant, parfaitement possible de reproduire ces fonctionnements. Vu qu'on veut appliquer ces changements sur plusieurs contrôleurs, on peut créer un nouveau contrôleur parent, qui sera étendu par les autres contrôleurs. Créons donc ce contrôleur à l'adresse fuel/app/classes/controller/agenda.php.

À noter qu'il est possible de créer ce contrôleur via Oil :

oil generate controller agenda

Mais, cette commande générera aussi des fichiers vues qui ne nous sont pas utiles (donc supprimez le dossier fuel/app/views/agenda/ si vous utilisez ce moyen). Pour atteindre le comportement cité plus haut, une implémentation possible d'un tel fichier est :

<?php
class Controller_Agenda extends Controller_Template{
    var $data = array(); // Donn�es � envoyer dans la vue
    var $title = 'Agenda'; // Titre de la page. D�faut : Agenda
    var $view_dir; // Dossier vue du controlleur.

    public function after($response)
    {
        $action_name     = Request::active()->action;
        $this->template->title   = $this->title;
        $this->template->content = View::forge($this->view_dir.'/'.$action_name, $this->data);

        return parent::after($response);
    }
}
?>

Lors d'un précédent article, nous avons expliqué l'ordre d'exécution lorsqu'une requête est exécutée. Tout ce qu'il faut comprendre ici, c'est que lorsqu'une requête est exécutée :

La fonction before est appelée
Puis c'est la fonction correspondant à l'action
Puis la fonction after
Puis le template est affiché

Ainsi, la fonction after sera toujours appelée après les actions des contrôleur étendant le contrôleur agenda.

Analysons le contenu de cette fonction :

Tout d'abord, on récupère le nom de l'action appelée via Request::active()->action.
On remplit l'attribut $this->template->title avec $this->title qui, par défaut, vaut 'Agenda' (donc pas besoin de le définir ; il y aura une valeur par défaut).
On remplit enfin l'attribut $this->template->content, qui va afficher la vue issue du fichier $this->view_dir/fichier-au-nom-de-l-action-appelee (le dossier sera défini dans le contrôleur). Les paramètres du fichier vue proviennent de $this->data, défini à l'appel à l'action.

Ainsi, le nouveau contrôleur Notes doit ressembler à :

<?php
class Controller_Notes extends Controller_Agenda
{
    var $view_dir = 'notes';

	public function action_index()
	{
		$this->data['notes'] = Model_Note::find_all();

	}

	public function action_view($id = null)
	{
		$this->data['note'] = Model_Note::find_by_pk($id);

	}

	public function action_create($id = null)
	{
		if (Input::method() == 'POST')
		{
			$val = Model_Note::validate('create');
			
			if ($val->run())
			{
				$note = Model_Note::forge(array(
					'titre' => Input::post('titre'),
					'description' => Input::post('description'),
				));

				if ($note and $note->save())
				{
					Session::set_flash('success', 'Added note #'.$note->id.'.');
					Response::redirect('notes');
				}
				else
				{
					Session::set_flash('error', 'Could not save note.');
				}
			}
			else
			{
				Session::set_flash('error', $val->show_errors());
			}
		}

	}

	public function action_edit($id = null)
	{
		$note = Model_Note::find_one_by_id($id);

		if (Input::method() == 'POST')
		{
			$val = Model_Note::validate('edit');

			if ($val->run())
			{
				$note->titre = Input::post('titre');
				$note->description = Input::post('description');

				if ($note->save())
				{
					Session::set_flash('success', 'Updated note #'.$id);
					Response::redirect('notes');
				}
				else
				{
					Session::set_flash('error', 'Nothing updated.');
				}
			}
			else
			{
				Session::set_flash('error', $val->show_errors());
			}
		}

		$this->template->set_global('note', $note, false);

	}

	public function action_delete($id = null)
	{
		if ($note = Model_Note::find_one_by_id($id))
		{
			$note->delete();

			Session::set_flash('success', 'Deleted note #'.$id);
		}

		else
		{
			Session::set_flash('error', 'Could not delete note #'.$id);
		}

		Response::redirect('notes');

	}


}

Les actions sont ainsi un peu plus courtes (le contenu de action_index ne fait qu'une seule ligne), on n'a plus besoin de spécifier la vue à afficher (ça nous permet aussi de forcer la norme "une action / une vue d'un même nom"), on ressemble plus aux frameworks existants et, enfin, on ne se préoccupe même plus du template.

On est d'accord ; le fonctionnement précédent était tout à fait acceptable. Le but de cette implémentation est avant tout de se simplifier la vie.

4. Affichage vue et liste

Dans la partie précédente, on est parti de la supposition qu'à chaque requête on n'affichait qu'une seule zone dans le template. Le cas de l'agenda est un peu plus spécifique, on affiche deux zones : la zone liste et la zone vue.

Tout d'abord, remplaçons dans le template :

<div class="inside">
     <?php echo $content; ?>
</div>

par

<div id="list_zone">
    <?php echo $list; ?>
</div>
<div id="view_zone">
    <div class="inside">
        <?php echo $view; ?>
   </div>
</div>

On peut maintenant afficher deux zones dans notre template $list et $view. Il suffit de modifier le contrôleur agenda pour remplacer l'attribut $this->template->content par $this->template->view. On peut également considérer que $this->template->list affichera toujours la même vue liste. On remplace alors la fonction after dans le contrôleur agenda par :

public function after($response)
{
    $action_name     = Request::active()->action;
    $this->template->title   = $this->title;
    $this->template->list = View::forge($this->view_dir.'/list', $this->data);
    $this->template->view = View::forge($this->view_dir.'/'.$action_name, $this->data);

    return parent::after($response);
}

Il faut cependant que la liste soit chargée. On peut le faire via la fonction after du contrôleur Notes :

public function after($response)
{
    $this->data['list'] = Model_Note::find(array('order_by' => array('titre' => 'asc')));

    return parent::after($response);
}

Il faut maintenant intégrer la vue liste affichant l’ensemble des notes. Créez le fichier fuel/app/views/notes/list.php.

<div class="list notes_list">
<?php if ($list): ?>
    <?php foreach ($list as $item): ?>
        <?php echo Html::anchor('notes/view/'.$item->id, $item->titre, array('class' => (isset($note) && $note->id == $item->id) ? 'active' : '')); ?>
    <?php endforeach; ?>
<?php else: ?>
<div>Pas de notes pour le moment</div>
<?php endif; ?>
</div>

Le script ressemble un peu au script index.php actuel. Il liste les notes, et si une note est sélectionnée (si $note est définie), il la surligne.

5. Vues CRUD

Quelques modifications doivent être apportées aux fichiers vues précédemment générés par Scaffold.

La vue index est affichée quand aucune note n’est sélectionnée. Il faut modifier son contenu en conséquence :

<div class="no_content">
    Vous pouvez s�lectionner une note<br/>
    ou <a href="<?php echo Uri::create('notes/create/') ?>">en cr�er une</a>
</div>

Lorsque l’on visualise une note, on aimerait, au lieu de devoir cliquer sur des liens, pouvoir effectuer des actions via un ensemble de boutons :

Étant donné qu’on veut pouvoir réutiliser ces boutons, il convient de créer un partial. Nous pouvons créer le partial fuel/app/views/_action_buttons.php :

<?php
    $menus = array(
        'edit'        => 'Modifier',
        'delete'    => 'Supprimer',
        'cancel'    => 'Annuler',
        'save'        => 'Sauvegarder',
        'add'        => 'Nouveau',
    );
?>
<div class="context_menu">
    <?php foreach ($menu as $item => $attr) {
        if (!is_array($attr)) {
            $attr = array('href' => $attr);
        }
        $attr['class'] = $item;
?>
        <a <?php echo array_to_attr($attr) ?> ><?php echo $menus[$item] ?></a>
    <?php } ?>
</div>

À noter que ce partial utilise la fonction array_to_attr, qui transforme un tableau en attributs pour les élément du DOM. Je vous invite à aller voir la documentation associée.

Les modifications suivantes tirent parti du partial _action_button et modifient légèrement le code pour des raisons cosmétiques.

fuel/app/views/notes/_form.php

<?php echo Form::open(); ?>
    <p>
        <?php echo Form::label('Titre', 'titre'); ?>
<?php echo Form::input('titre', Input::post('titre', isset($note) ? $note->titre : '')); ?>
    </p>
    <p>
        <?php echo Form::label('Description', 'description'); ?>
<?php echo Form::textarea('description', Input::post('description', isset($note) ? $note->description : '')); ?>
    </p>
<?php echo Form::close(); ?>

fuel/app/views/notes/create.php

<?php
echo render('_action_buttons', array(
            'menu' => array(
                'save' => array('href' => '#', 'onclick' => "$(this).closest('#view_zone').find('form').submit(); return false;"),
                'cancel' => Uri::create('notes/index'),
            )
        )
    );
?>
<?php echo render('notes/_form'); ?>

fuel/app/views/notes/edit.php

<?php
echo render('_action_buttons', array(
            'menu' => array(
                'save' => array('href' => '#', 'onclick' => "$(this).closest('#view_zone').find('form').submit(); return false;"),
                'cancel' => Uri::create('notes/view/'.$note->id),
            )
        )
    );
?>
<?php echo render('notes/_form'); ?>

fuel/app/views/notes/view.php

<?php
    echo render('_action_buttons', array(
            'menu' => array(
                'add' => Uri::create('notes/create'),
                'edit' => Uri::create('notes/edit/'.$note->id),
                'delete' => Uri::create('notes/delete/'.$note->id),
            )
        )
    );
?>
<label>Titre</label>
    <?php echo $note->titre; ?>
<label>Description</label>
    <?php echo nl2br($note->description); ?>

6. Support de la catégorie “Adresses et numéros”

On peut désormais ajouter le support pour la catégorie “Adresses et numéros”. Cette catégorie affiche, en fait, une liste de personnes. Nous appellerons donc son contrôleur People.
On génère d’abord le code par Scaffold :

php oil generate scaffold/crud person name:string surname:string tel:string email:string address:text additionals:text

Élément intéressant dans la génération, la gestion du singulier / pluriel. On a appelé un scaffold basé sur le nouvel objet Person, mais Oil a généré un modèle person.php ainsi qu'un fichier migration 002_create_people.php. C’est un choix que fait aussi Rails. Attention cependant, le singulier / pluriel n’est probablement bien géré qu’en anglais.

La liste des fichiers générés est presque similaire, seul le template n’a pas été généré car il est déjà présent.

Il faut maintenant lancer la migration :

php oil refine migrate

Pour l’implémentation des vues et du contrôleur People, vous pouvez copier les fichiers à partir du dossier source. Sinon, ça peut être une bon exercice d’adapter les fichiers générés à partir du scaffold.

Juste un remarque : rendez-vous dans le fichier modèle généré fuel/app/classes/model/person.php.

<?php
class Model_Person extends Model_Crud
{
	protected static $_table_name = 'people';
	
	public static function validate($factory)
	{
		$val = Validation::forge($factory);
		$val->add_field('name', 'Name', 'required|max_length[255]');
		$val->add_field('surname', 'Surname', 'required|max_length[255]');
		$val->add_field('tel', 'Tel', 'required|max_length[255]');
		$val->add_field('email', 'Email', 'required|valid_email|max_length[255]');
		$val->add_field('address', 'Address', 'required');
		$val->add_field('additionals', 'Additionals', 'required');

		return $val;
	}

}

Si on analyse la fonction validate, tous les champs string ont le validateur required|max_length[255] et tous les champs text ont le validateur required (hormis email qui a le validateur required|valid_email|max_length[255], qui teste s'il s'agit d'un email valide). Lorsqu'un champ s'appelle email, Oil ajoute automatiquement ce validateur. Il s'agit d'une valeur spéciale (apparemment la seule, pour le moment), donc sachez que le choix du nom du champ peut aussi avoir un impact sur le code généré par Scaffold.

7. Renommer la colonne titre

Les plus attentifs d'entre vous ont dû remarquer qu'on est passé à une notation en anglais. Pourtant, dans le modèle note, on a une colonne titre en français. Nous allons renommer cette colonne par le système de migration.

php oil generate migration rename_field_titre_to_title_in_notes

Jetons un coup d'œil au fichier généré :

<?php

namespace Fuel\Migrations;

class Rename_field_titre_to_title_in_notes
{
	public function up()
	{
		\DBUtil::modify_fields('notes', array(
			'titre' => array('name' => 'title', 'type' => 'varchar', 'constraint' => 255)
		));
	}

	public function down()
	{
    \DBUtil::modify_fields('notes', array(
			'title' => array('name' => 'titre', 'type' => 'varchar', 'constraint' => 255)
		));
	}
}

Le générateur nous a généré une classe avec deux fonctions : la fonction up et la fonction down. Ces deux fonctions permettent d'effectuer les migrations. Up est appelée lorsqu'on veut effectuer la migration, down quand on souhaite l'annuler.

Nous avons fait appel à une migration magique, si bien que ces fonctions sont pré-remplies. Si on avait généré la migration avec un nom différent, les fonctions auraient probablement été vides. Je vous invite à consulter la documentation associée.

La fonction \DBUtil::modify_fields semble souffrir, pour l'instant, d'un léger dysfonctionnement. Je vous conseille donc de remplacer les fonctions up et down. C'est l'occasion de comprendre les requêtes sensées être exécutées.

public function up()
{
        \DB::query('ALTER TABLE `notes` CHANGE `titre` `title` VARCHAR( 255 )')->execute();
}

public function down()
{
        \DB::query('ALTER TABLE `notes` CHANGE `title` `titre` VARCHAR( 255 )')->execute();
}

Lorsqu'on exécute :

php oil refine migrate

C'est la fonction up qui est appelée. La colonne titre est alors renommée en title. Si on veut revenir en arrière (à cause, mettons, d'une fausse manipulation), on peut exécuter :

php oil refine migrate:down

C'est la fonction down qui est alors exécutée.

Je vous invite à consulter la documentation associée.

Une fois la migration effectuée, n'oubliez pas d'aller modifier le code.

Pistes d'améliorations

L'agenda que nous avons développé est loin d'être terminé. Voici quelques améliorations possibles. Certains de ces points feront l'objet de tutoriels prochainement.

Il serait parfaitement possible de rajouter un système d'authentification. On pourrait, par exemple, créer une table user, puis rajouter des colonnes user_id dans les tables notes et person. On utiliserait la classe Session. Vous pouvez consulter la documentation associée.
Pour le modèle Person, les champs ne sont-ils peut-être pas tous obligatoires par défaut ? Peut-être faut-il rajouter des conditions de validation supplémentaires ? Vous pouvez aussi consulter la documentation associée.
La page d'accueil demande aussi à être changée (elle est toujours sur welcome). Si on veut que la page d'accueil pointe vers les notes, on peut modifier le fichier fuel/app/config/routes.php et remplacer : '_root_' => 'welcome/index' par '_root_' => 'notes/index'. Les possibilité des routes sont multiples, je vous conseille de consulter la documentation associée.

jQuery UI Button : buttonset de radio/checkbox avec seulement des ic�nes

Gilles Felix — Mon, 09 Jan 2012 17:46:00 +0100

Voici un petit billet pour faire profiter d'une astuce pour le widget jQuery UI Button : cr�er un buttonset (regroupement de boutons comme sur l'image illustrant ce billet) bas� sur des inputs radio (ou checkbox)

Si vous lisez attentivement la documentation et les exemples du widget Button de jQuery UI, vous saurez très facilement créer un buttonset à partir d'une liste d'inputs radio ou checkbox. Techniquement, le widget récupère les LABEL associés aux INPUT pour créer les BUTTONS. L'avantage de passer par des radio ou des checkbox est que le widget gère l'état on / off du boutton en fonction de l'attribut checked de l'INPUT.

Dans un autre exemple, vous apprenez à créer des bouttons avec un ou deux icônes, avec ou sans texte.

Oui, mais vous ce que vous voulez, c'est un groupe de boutons basés sur des radio ou des checkbox ET représentés seulement par des icônes. Et là, pas d'exemple disponible.

J'ai d'abord essayé de mettre les icônes directement dans les LABEL, via un tag IMG ou via un SPAN avec la classe CSS ui-icon. Mais, le résultat n'était pas convainquant : les boutons étaient plus gros qu'à la normale.

J'ai essayé de simuler l'effet radio (ou checkbox) avec un boutton classique et en forçant la classe CSS ui-state-active sur le bouton actif. Mais, le widget, dans les cas non radio ou checkbox, enlève la classe ui-state-active sur le mouseout.

J'ai donc mis le nez dans le code du widget pour voir comment il marchait. C'est du bel ouvrage !! Dans la partie spécifique aux buttonset, j'ai remarqué que le widget cherchait tous les :button, :submit, :reset, :checkbox, :radio, a, :data(button) contenus dans l'élément englobant. Ensuite, pour chacun, il vérifiait s'il avait déjà été transformé en ui-button. Si oui, il le rafraichissait, si non, il l'initialisait. BINGO !

La voilà ma solution : d'abord initialiser un à un mes inputs radio en passant les bons paramètres et seulement ensuite initialiser le buttonset.

//En partant du principe que le suffixe de l'ic�ne � afficher est contenu dans la valeur de chaque radio

// On cherche tous les radio contenu dans un �l�ment servant de container au groupement de boutons
$('#buttonset').find(':radio')

// Boucle sur les radios
.each(function() {
    var input = $(this);
    // Initialisation du bouton : 1 ic�ne mais le label non affich�
    input.button({
        text : false,
        icons : {
             primary: 'ui-icon ui-icon-' + input.val()
        }
    });
})

// On revient au groupement de boutons et on l'initialise
.end()
.buttonset();

Et le résultat (vous pouvez faire joujou avec sur JSBin).

Vous pourrez également voir le résultat en live d'ici quelques jours / heures dans la démo de Novius OS, application Médiathèque.

Tutoriel : Cr�ation d'un projet avec FuelPHP

S�bastien Drouyer — Wed, 14 Dec 2011 10:37:00 +0100

La semaine derni�re, j�ai rejoint l��quipe du projet open-source Novius OS bas� sur le framework FuelPHP. Mes coll�gues de Novius Labs m�ont initi� � ce nouveau framework. Je prends donc la suite de Julian pour vous en expliquer le fonctionnement. Aujourd�hui, on rentre dans le d�tail et passons � un cas concret.

Note du 20/12/2011 : cet article a été mis à jour par rapport à la nouvelle version 1.1 de Fuel sortie récemment. Les codes affichés, les commandes ainsi que certaines prises d'écran ont donc sensiblement changés depuis la version initiale.

Objectif

Sommaire du tutoriel
Développer sous FuelPHP

L’objectif de cet article n’est pas d’être exhaustif sur le framework, mais de vous donner les armes nécessaires pour commencer un projet. La connaissance d’un framework PHP ou autre (Ruby on Rails, Symfony, CakePHP...) est un plus mais n’est pas nécessaire pour suivre ce tutoriel.

Tout au long des articles 3 et 4 de notre tutoriel FuelPHP, nous allons nous baser sur un exemple : l’élaboration d’un agenda accessible via internet (où il est possible d’écrire des notes, d’entrer ses contacts etc...).

Pour les curieux, voici un aperçu :

Vous vous en doutez, la réalisation graphique ne fait pas partie des objectifs de ce tutoriel. Je tiens néanmoins à donner le crédit des icônes issues de l’excellent site the Noun Project.

Ce tutoriel part du principe que vous avez lu l’article précédent de Julian et installé une instance du projet. Nous utiliserons MySQL et un logiciel de gestion de base de données (phpMyAdmin).

Configuration de la base de données

Via votre logiciel de gestion de base de données préféré, créez une base de données que vous nommerez tuto_agenda.

Il faut maintenant configurer FuelPHP pour qu’il puisse accéder à cette base.

Il faut d’abord modifier le fichier fuel/app/config/db.php qui va vous permettre d’accéder à votre serveur MySQL. Voici ce que contient le fichier de base :

return array(
	'active' => 'default',

	/**
	 * Base config, just need to set the DSN, username and password in env. config.
	 */
	'default' => array(
		'type'        => 'pdo',
		'connection'  => array(
			'persistent' => false,
		),
		'identifier'   => '`',
		'table_prefix' => '',
		'charset'      => 'utf8',
		'caching'      => false,
		'profiling'    => false,
	),

	'redis' => array(
		'default' => array(
			'hostname'  => '127.0.0.1',
			'port'      => 6379,
		)
	),

);

On peut voir qu’on peut ici spécifier les informations de connexion (le type, l’adresse et le port du serveur - type, hostname et port) ainsi que certaines options (gestion du cache, le préfixe à utiliser devant chaque table...).

Le type de base est PDO. Il est possible de le laisser tel quel, cependant certaines opérations de migration de ce type ne sont pas encore supportées par FuelPHP. Nous allons donc modifier ce type en MySQL. Nous ne modifierons aucun des autres paramètres, ce n’est pas l’objet de ce tutoriel.

return array(
	'active' => 'default',

	/**
	 * Base config, just need to set the DSN, username and password in env. config.
	 */
	'default' => array(
		'type'        => 'mysql',
		'connection'  => array(
			'persistent' => false,
		),
		'identifier'   => '`',
		'table_prefix' => '',
		'charset'      => 'utf8',
		'caching'      => false,
		'profiling'    => false,
	),

	'redis' => array(
		'default' => array(
			'hostname'  => '127.0.0.1',
			'port'      => 6379,
		)
	),

);

Il faut maintenant spécifier les identifiants et la base sur laquelle se connecter. Le framework FuelPHP propose, par défaut, de séparer cette partie de la configuration entre mode de développement et mode de production. Nous allons suivre cette démarche, mais sachez qu’il est possible de tout configurer dans le fichier précédent. A l'inverse, il est possible de spécifier des bases de données différentes et d’autres configurations dans les fichiers de configuration développement / production.

Si la configuration n’a pas été modifiée, nous sommes normalement en mode développement. Ouvrez donc le fichier fuel/app/config/development/db.php. Le contenu de base est le suivant :

return array(
	'default' => array(
		'connection'  => array(
			'dsn'        => 'mysql:host=localhost;dbname=fuel_dev',
			'username'   => 'root',
			'password'   => 'root',
		),
	),
);

Cette configuration est adaptée au type de connexion PDO. Il faut l’adapter au type MySQL et à vos propres informations de connexion. Remplacez par le code ci-dessous en modifiant votre identifiant et votre mot de passe :

return array(
	'default' => array(
		'connection'  => array(
		    'hostname'   => 'localhost',
		    'database'   => 'tuto_agenda',
			'username'   => 'IDENTIFIANT',
			'password'   => 'MOT DE PASSE',
		),
	),
);

La configuration de la base de données est normalement maintenant terminée. Il est temps de passer à la création de l'agenda.

Le principe

1. Génération de code par Scaffold

Nous allons maintenant générer un code de base, qui va nous permettre d’avoir un aperçu du fonctionnement de FuelPHP. Il existe, dans beaucoup de frameworks (comme Rails), la possibilité de générer du code via Scaffold. Ce code permet de gérer les actions de base d’un objet (visualisation, création, modification, suppression - CRUD en anglais). C’est l’idéal pour avoir une base de développement !

Beaucoup d’opérations peuvent s’effectuer sous FuelPHP avec le script Oil (remarquez fuel / oil). Ce script permet notamment de générer des migrations, des modèles, des contrôleurs... et le scaffolding.

Un agenda contient notamment une partie où il est possible de gérer des notes, qui contiennent un titre et une description. Nous allons générer le code via la ligne de commande suivante (après s’être rendu dans le répertoire root du projet) :

php oil generate scaffold/crud notes titre:string description:text

Vous pouvez remarquer que l’écriture de cette ligne de commande est assez simple :

php oil generate scaffold/crud <NOM DE LA TABLE> <ATTRIBUT>:<TYPE> <ATTRIBUT>:<TYPE> <ATTRIBUT>:<TYPE>...

Notez que l'extension scaffold/crud indique que l'on souhaite utiliser la structure CRUD. Oil peut générer du code suivant d'autres structure (comme orm). La différence se fera notamment voir au niveau du code généré dans les modèles (qui n'étenderont pas les mêmes classes).

Lorsque la commande est exécutée, Oil nous indique l’ensemble des fichiers qui ont été modifiés :

Vous pouvez voir qu’il y en a un certain nombre :

fuel/app/classes/model/note.php : le modèle associé aux notes
fuel/app/migrations/001_create_notes.php : le fichier migration, qui nous permettra de migrer la base de donnée en créant la table notes.
fuel/app/classes/controller/notes.php : le contrôleur associé aux notes
tous les fichiers dans fuel/app/views/notes/ qui sont les vues associées aux actions
fuel/app/views/template.php qui est la vue implémentant la structure de la page

2. Migration de la base de données

Si le fichier migration a bel et bien été généré, la table n’a pas été créée pour autant. Il y a dans Oil une commande permettant d’éxécuter ces fichiers migration.

php oil refine migrate

Oil permet une liberté beaucoup plus grande au niveau des migrations, nous y reviendrons plus tard.

Une fois la commande executée, vous pouvez voir que la base de données n’est plus vide. Elle contient maintenant deux tables :

Il y a la table migration, qui enregistre quelles migrations ont été effectuées. Nous y reviendrons plus tard.

Il y a ensuite la table notes que nous voulions créer. Jetons un coup d’œil à la structure :

A partir des deux colonnes que nous avons spécifiées à Oil pour le scaffold (titre et description), il en a généré cinq :

id : identifiant de la note avec son index primary associé
titre : le titre de la note. Nous avons spécifié un type string, vous savez maintenant que l’équivalence MySQL est varchar(255)
description : la description de la note
created_at : date de création de la note. Est gérée par défaut dans le modèle.
updated_at : date de modification de la note. Est gérée par défaut dans le modèle.

A noter qu’il est possible de désactiver la création des colonnes created_at et updated_at en éditant le fichier de migration (si vous générez le modèle via generate model, il y a aussi l’option --no-timestamp, mais pour le moment elle ne semble pas prise en compte pour le scaffolding).

La présence de ces colonnes n’est pas gênante et sera probablement utile, donc laissons les.

3. Aperçu

La page d’accueil n’a toujours pas changé, mais il est possible maintenant d’accéder aux notes via l’adresse suivante (si vous avez suivi l’installation de Julian) :

http://localhost/mon_site_fuel/public/notes si la redirection est activée
http://localhost/mon_site_fuel/public/index.php/notes sinon

Le tout doit normalement ressembler à :

Liste des notes

Création / édition d'une note

Vue d'une note

Le code généré gère même les notifications :

Après mise à jour d'une note

4. Le code généré

Maintenant que le système fonctionne, nous pouvons jeter un coup d’œil au code généré.

Le scaffold a généré un modèle, situé dans fuel/app/classes/model/note.php qui contient :

<?php
class Model_Note extends Model_Crud
{
	protected static $_table_name = 'notes';
	
	public static function validate($factory)
	{
		$val = Validation::forge($factory);
		$val->add_field('titre', 'Titre', 'required|max_length[255]');
		$val->add_field('description', 'Description', 'required');

		return $val;
	}

}

Le contenu est assez simple, car notre modèle étend la classe Model_Crud, qui contient déjà les fonctions de bases, nous permettant de manipuler l’objet dans le code. Il y a une seule variable, $_table_name qui, comme son nom l’indique, définit le nom de la table associée au modèle. Il y a aussi une fonction, validate, qui permet d'imposer des conditions lors de la sauvegarde d'un élément. Par exemple, lors de la sauvegarde d'une note, le titre ne doit pas être vide et sa longueur ne doit pas dépasser 255 caractères. La description elle aussi ne doit pas être vide. Il est possible d'avoir dans ce domaine un degré beaucoup plus grand de liberté, nous y reviendrons plus tard.

Le scaffold a aussi généré un contrôleur, situé dans fuel/app/classes/controller/notes.php, qui contient (j’ai résumé certaines actions) :

<?php
class Controller_Notes extends Controller_Template 
{

	public function action_index()
	{
		$data['notes'] = Model_Note::find_all();
		$this->template->title = "Notes";
		$this->template->content = View::forge('notes/index', $data);

	}

	public function action_view($id = null)
	{
		$data['note'] = Model_Note::find_by_pk($id);

		$this->template->title = "Note";
		$this->template->content = View::forge('notes/view', $data);

	}

	public function action_create($id = null)
	{
		//...
	}

	public function action_edit($id = null)
	{
		//...
	}

	public function action_delete($id = null)
	{
		//...

	}


}

On peut voir que le contrôleur est composé de cinq fonctions, commençant toutes par action_. Il s’agit des actions du contrôleur. Si, par exemple, vous vous rendez sur :

http://localhost/mon_site_fuel/public/notes/create ou
http://localhost/mon_site_fuel/public/index.php/notes/create sans redirection

C’est la fonction action_create qui sera appelée dans le contrôleur.

Quant à l’adresse :
http://localhost/mon_site_fuel/public/notes/
elle est équivalente (par défaut) à l’adresse :
http://localhost/mon_site_fuel/public/notes/index
Donc appelera bien l’action action_index.

Analysons la fonction action_index (qui, comme vous pouvez le déduire de l’adresse, liste l’ensemble des notes qui ont été créées) :

La première ligne charge l’ensemble des notes grâce à la fonction statique find_all. Cette fonction peut bien sûr recevoir d’autres paramètres, je vous invite à consulter la documentation associée.
La seconde et la troisième lignes modifient toutes les deux des attributs de $this->template, un attribut title (qui est vraisemblablement le titre de la page) et un attribut content, auquel est affectée la vue. Je reviendrai un peu plus tard sur cette affectation.

L’objet qui a été modifié est l’instanciation d’un template (qui est la structure de la page). Pour faire court, les attributs de cet objet vont pouvoir être récupérés par le template. Ce template a lui aussi été généré via le scaffold. Il est présent dans l’adresse fuel/app/views/template.php. Son contenu est le suivant (j’ai résumé le style pour plus de lisibilité) :

<!DOCTYPE html>
<html>
<head>
	<meta charset="utf-8">
	<title><?php echo $title; ?></title>
	<?php echo Asset::css('bootstrap.css'); ?>
	<style>
		body { margin: 40px; }
	</style>
</head>
<body>
	<div class="container">
		<div class="row">
			<div class="span16">
				<h1><?php echo $title; ?></h1>
				<hr>
<?php if (Session::get_flash('success')): ?>
				<div class="alert-message success">
					<p>
					<?php echo implode('</p><p>', (array) Session::get_flash('success')); ?>
					</p>
				</div>
<?php endif; ?>
<?php if (Session::get_flash('error')): ?>
				<div class="alert-message error">
					<p>
					<?php echo implode('</p><p>', (array) Session::get_flash('error')); ?>
					</p>
				</div>
<?php endif; ?>
			</div>
			<div class="span16">
<?php echo $content; ?>
			</div>
		</div>
		<footer>
			<p class="pull-right">Page rendered in {exec_time}s using {mem_usage}mb of memory.</p>
			<p>
				<a href="http://fuelphp.com">FuelPHP</a> is released under the MIT license.<br>
				<small>Version: <?php echo e(Fuel::VERSION); ?></small>
			</p>
		</footer>
	</div>
</body>
</html>

Ainsi, la valeur de l’attribut $this->template->title est accessible via la variable $title dans le template. Si on modifie dans action_index :

$this->template->title = "Mes notes";

Lorsqu’on se rendra de nouveau sur http://localhost/mon_site_fuel/public/notes/, le titre aura été modifié :

Sachez qu’il est possible de modifier tous les attributs de $this->template (comme $this->template->description par exemple). Cet attribut sera alors accessible en tant que variable ($description) dans le template. Il est aussi possible de changer de template, nous y reviendrons plus tard.

Revenons au contrôleur, la dernière affectation, comme je le disais, affecte le contenu de la vue :

$this->template->content = View::forge('notes/index', $data);

View::forge retourne la vue située dans fuel/app/views/notes/index.php avec les variables définies dans $data. Jetons un coup d’oeil à ce fichier :

<h2>Listing Notes</h2>
<br>
<?php if ($notes): ?>
<table class="zebra-striped">
	<thead>
		<tr>
			<th>Titre</th>
			<th>Description</th>
			<th></th>
		</tr>
	</thead>
	<tbody>
<?php foreach ($notes as $note): ?>		<tr>

			<td><?php echo $note->titre; ?></td>
			<td><?php echo $note->description; ?></td>
			<td>
				<?php echo Html::anchor('notes/view/'.$note->id, 'View'); ?> |
				<?php echo Html::anchor('notes/edit/'.$note->id, 'Edit'); ?> |
				<?php echo Html::anchor('notes/delete/'.$note->id, 'Delete', array('onclick' => "return confirm('Are you sure?')")); ?>

			</td>
		</tr>
<?php endforeach; ?>	</tbody>
</table>

<?php else: ?>
<p>No Notes.</p>

<?php endif; ?><p>
	<?php echo Html::anchor('notes/create', 'Add new Note', array('class' => 'btn success')); ?>

</p>

La fonction View::forge retourne donc le contenu du fichier executé en PHP avec les variables définies dans $data. Ainsi $data[‘notes’] est accessible via la variable $notes dans la vue index.php.

On peut remarquer au passage dans le fichier de nombreux appels à la fonction Html::anchor. Il s’agit d’un helper, c’est à dire d’une fonction retournant des bouts de code en Html. Dans ce cas ci il s’agit d’un lien, avec comme classes css btn success :

<?php echo Html::anchor('notes/create', 'Add new Note', array('class' => 'btn success')); ?>

est équivalent à

<a class="btn success" href="http://localhost/mon_site_fuel/public/notes/create">Add new Note</a>

Il est parfaitement possible de s’en passer et d’écrire ce code HTML directement. Html::anchor permet cependant de se simplifier la vie (vous pouvez voir qu’il écrit l’url complète), et l’utilisation d’helpers de manière générale permet d’améliorer la maintenabilité (on peut imaginer faire une surcouche à Html::anchor pour passer de liens directs à des requêtes en ajax par exemple, le tout en ne modifiant qu’un seul bout de code).

La fonction Html::anchor supporte d’autres paramètres. Je vous invite à consulter la documentation associée.

Pour résumer :

Lorsqu’un utilisateur se rend dans une adresse d’un site fuelPHP
http://localhost/mon_site_fuel/public/notes/
Une fonction du contrôleur notes est appelée (le cas présent action_index)
Cette fonction charge les variables qui lui sont nécessaires, affecte les attributs de $this->template (que ce soit directement une chaine de caractère ou le retour d’un View::Forge)
Le template est affiché à l’utilisateur

Si vous avez eu l’occasion d’utiliser d’autres framework, vous avez probablement remarqué qu’il n’est souvent pas nécessaire de spécifier la vue dans l’action. Par exemple dans l’action action_index :

public function action_index()
{
	$data['notes'] = Model_Note::find_all();
	$this->template->title = "Mes notes";
	$this->template->content = View::forge('notes/index', $data);

}

Il n’est pas là nécessaire de définir $this->template->title, ni $this->template->content (pour chaque action, une vue est attibuée par défaut). Cette politique permet de limiter les répétitions dans le code.

Avec FuelPHP, ce comportement n’est pas disponible par défaut mais, grâce à la fonction after, que nous verrons plus tard, il est possible de l’imiter. C’est donc avant tout une force du framework, qui laisse une liberté plus grande au niveau des templates.

5. Paramètres et actions

Le traitement des paramètres dans les actions est un point important, car il va vous permettre notamment d’interagir avec l’internaute.

a. Via les paramètres d’une action

Jetons un coup d’oeil à l’action action_view (qui permet de visualiser une note en particulier) dans le contrôleur notes :

public function action_view($id = null)
{
	$data['note'] = Model_Note::find_by_pk($id);

	$this->template->title = "Note";
	$this->template->content = View::forge('notes/view', $data);

}

On peut remarquer la présence d’un paramètre dans la déclaration, contrairement à action_index. Lorsqu’on fait appel à l’action action_view, c’est qu’on veut charger une note en particulier, que l’on récupère grâce à l’identifiant.

Ainsi, lorsque l’utilisateur accédera à l’adresse :
http://localhost/mon_site_fuel/public/notes/view/1

La fonction action_view sera appelée avec comme paramètre $id = 1. Il est parfaitement possible de multiplier le nombre de paramètres.

b. Via la classe Input

Si vous jetez un coup d’œil à la fonction action_create, vous pouvez remarquer la présence de Input::post.

Input::post et Input::get permettent de récupérer les valeurs $_POST et $_GET respectivement. Je vous invite à consulter la documentation associée.

6. Les partials

Si vous consultez les fichiers vues fuel/app/views/notes/edit.php et fuel/app/views/notes/create.php, vous remarquez une ligne en commun dans les deux fichiers :

<?php echo render('notes/_form'); ?>

Ils incluent tous les deux un partial, c’est à dire un bout de vue. En effet, si on compare le formulaire de création et d’édition, les deux vues sont très similaires. Elles font donc appel toutes les deux à un même partial (bout de vue), reprenant le formulaire. L’appel à des partials permet de limiter la répétition du code et donc d’améliorer la maintenabilité d’un logiciel. A utiliser tant que possible !

La fonction render permet donc de renvoyer le contenu executé d’un partial, dans notre cas fuel/app/views/notes/_form.php. Voici le contenu :

<?php echo Form::open(array('class' => 'form-stacked')); ?>

	<fieldset>
		<div class="clearfix">
			<?php echo Form::label('Titre', 'titre'); ?>

			<div class="input">
				<?php echo Form::input('titre', Input::post('titre', isset($note) ? $note->titre : ''), array('class' => 'span6')); ?>

			</div>
		</div>
		<div class="clearfix">
			<?php echo Form::label('Description', 'description'); ?>

			<div class="input">
				<?php echo Form::textarea('description', Input::post('description', isset($note) ? $note->description : ''), array('class' => 'span10', 'rows' => 8)); ?>

			</div>
		</div>
		<div class="actions">
			<?php echo Form::submit('submit', 'Save', array('class' => 'btn primary')); ?>

		</div>
	</fieldset>
<?php echo Form::close(); ?>

A noter qu’on accède à la variable $note. En effet, cette variable est accessible car dans l'action edit on peut voir cette ligne :

$this->template->set_global('note', $note, false);

Cette variable est affectée au template en tant que globale et est donc accessible à toutes les vues, sans avoir à la passer dans leurs paramètres. Ce comportement peut être pratique si on a une variable qu'on veut accéder partout (comme l'utilisateur enregistré en session ou une configuration globale), mais est peu recommandée pour les autres cas car elle réduit la lisibilité du code.

Le partial fait notamment appel à la classe helper Form, qui permet d’instancier un formulaire et des champs en HTML. Je vous invite à consulter la documentation associée.

J'espère que cet article vous a permis de vous lancer sur FuelPHP. N'hésitez pas à me contacter en commentaire ou sur Twitter si vous avez des questions. Dans un article prochain, nous passerons à l'action ! Avec les connaissances acquises dans cet article, nous finaliserons notre agenda en améliorant l'affichage, en organisant un menu, en complexifiant notre modèle de données et, enfin, en mettant en place un système d'authentification.

https://fuelphp.com/blog/2011/12/version-1-1-finally-lands

Pourquoi j'ai besoin d'un Dribbble for Words

Antoine Lefeuvre — Thu, 24 Nov 2011 16:20:00 +0100

A la question "quels livres doit lire un cr�ateur de sites web", je r�ponds Elements of User Experience de Jesse James Garett et Getting Real de 37signal. Oui, ils ont tous deux plus de cinq ans, je vois �a comme un atout. Il y a cinq ans donc, Jason Fried nous disait : copywriting is interface design. Cinq ans. Il serait temps de passer � l'action.

Combien de pixels mesure ton interface ?

En septembre dernier, Des Traynor d'Intercom nous présentait son idée d'un Dribbble for Words à l'occasion de sa conférence The Language of Interfaces à Londres. Dribbble est une communauté populaire, réservée aux designers, où sont publiés et commentés des pixels. On y parle image sous toutes ses formes : logo, identité visuelle, print, j'en passe, et UI. Je partage l'opinion de Des Traynor à l'endroit de Dribbble : je n'ai absolument rien contre, mais il s'agit de graphisme, ni plus, ni moins.

Ainsi, pour que les interfaces ne soient plus exprimées uniquement en pixels, complétons Dribbble d'un Wordddle, d'un Scribbble ou encore d'un Palabbbras (quitte à parler langue, pourquoi se limiter à l'anglais ?). Voilà ce que j'y ferais.

Ma semaine sur Palabbbras

J'aurais commencé par voir cette proposition de l'équipe de Capitaine Train (au passage, merci Capitaine Train de m'avoir fait oublier Voyages SNCF). J'aurais bien sûr réagi, voyez mon commentaire ci-dessous.

Quelques jours plus tard, ç'aurait été à mon tour de faire part d'un de nos problèmes et de notre solution. Mon objectif : évaluer notre proposition en la confrontant à l'avis d'autres UX designers.

Tout le monde n'est pas convaincu

Alors que l'idée d'un Dribbble for Words n'avait que quatre jours, Tim Meany d'Arc90 y réagissait négativement... mais avec beaucoup d'humour. A l'aide d'un dessin génial (remarquez le "1776 views"), il souligne l'importance du contexte. Il doute qu'on puisse discuter d'un texte sans connaître le site ou l'application dont il est issu.

Loin de moi l'idée de remettre en cause le rôle central du contexte, mais je pense qu'on peut le résumer, l'expliquer. C'est pourquoi sur mes interfaces de Palabbbras, j'ai intégré un "notre problème" de même taille que "notre solution" (contrairement au purpose de Wordddle, trop discret), ainsi que "voir la solution en action" (les pixels sont ici au service des mots).

On pourrait même aller plus loin dans l'explication du contexte, en se basant sur le microcopy framework, toujours de Des Traynor :

Et vous, qu'en pensez-vous ? Qui est partant pour un Dribbble for Words ?

FuelPHP : mise en place de l'environnement

Julian Esp�rat — Tue, 22 Nov 2011 17:31:00 +0100

Au programme de cet deuxi�me article consacr� � FuelPHP :
Installation du framework
Structure des fichiers
Traitement et ex�cution d'une requ�te
Configuration de l'application

Installation via la ligne de commande

Sommaire du tutoriel
Développer sous FuelPHP

Pour les habitués de Git et de la ligne de commande sous Linux, vous pouvez aller faire un tour sur la page de la documentation officielle qui vous explique comment mettre tout ça en place : http://docs.fuelphp.com/installation/instructions.html

Pour tous les autres moins doués (comme moi), il y a la méthode classique :

Installation manuelle

Télécharger la version la plus récente des sources ici : http://docs.fuelphp.com/installation/download.html

À l’heure où j’écris cet article, il existe une version plus récente que je vous recommande : https://github.com/downloads/fuel/fuel/fuelphp-v1.1.zip (sortie le 13 décembre 2011).

Mettre ça dans votre dossier d’hébergement, par exemple c:\wamp\www\mon_site_fuel\ (WampServer sous Windows) ou /var/www/mon_site_fuel/ (Linux).

Information sécurité ! En théorie, seul le répertoire public/ doit être accessible via l’URL. Hors, avec notre installation, le répertoire fuel/ et le fichier oil le sont également. Ce qui n'est pas nécessaire et présente un risque de sécurité, car ils ne sont pas prévus pour ça.
Pour notre environnement en local, ça n'est pas très grave, mais n’utilisez pas cette configuration ailleurs qu’en local !

Pour résoudre ce problème de sécuité, si vous en avez la possibilité et que vous savez comment faire, utilisez le répertoire public/ en tant que Document Root pour votre installation.

Désormais, si vous allez sur http://localhost/mon_site_fuel/public/index.php vous devriez voir la page de bienvenue qui s’affiche et vous félicite :

Réécriture d'URL

Fuel fournit un fichier .htaccess pour Apache pour utiliser la réécriture d'URL lorsque c'est possible.

Avec la réécriture, les URL seront de la forme http://localhost/mon_site_fuel/public/votre/page/ici
Sans la réécriture, les URL seront de la forme http://localhost/mon_site_fuel/public/index.php/votre/page/ici

La réécriture permet donc d'avoir des URL plus jolies en supprimant la partie index.php dans l'URL.

Structure des fichiers proposée par défaut

Avant d’aller plus loin, il est important de voir les répertoires qui existent et ce qu’ils contiennent :

Vous trouverez trois choses importantes à la racine :

fuel/ : le code PHP c’est par ici
public/ : dossier accessible depuis le navigateur (images, CSS, JavaScript, etc.)
oil : l’exécutable ligne de commande de FuelPHP

Le répertoire fuel/ contient trois sous-répertoires importants :

app/ : votre application (configuration, contrôleurs, modèles, vues, etc.)
core/ : le cœur de FuelPHP. Nous l’appellerons Core.
packages/ : extensions du Core qui sont séparées car facultatives

Les chemins vers ces trois répertoires sont définis dans le fichier public/index.php, et sont donc modifiables facilement si vous le voulez. :-)

Enfin, la partie importante pour nous (celle que nous allons modifier) se situe dans le dossier fuel/app/ :

config/ : toute la configuration, notamment le fichier général config.php
classes/ : contrôleurs, modèles, helpers, logique métier. Quand vous créez un fichier PHP c’est probablement ici qu’il trouve sa place !
- controller/ : les contrôleurs
- model/ : les modèles utilisés par l'ORM
views/ : les vues et templates

D’autres dossiers qui nous concernent moins pour le moment sont également présents :

cache/
lang/
logs/
modules/

Assurez-vous juste à ce que cache/ et logs/ soient inscriptibles (droits d'écriture w).

Répondre à une requête de l'internaute

Tout commence par public/index.php qui sert de contrôleur frontal (toutes les requêtes passent par ce fichier) :

Étape 1, initialisation :
- Les constantes vers les trois répertoires principaux sont définies : APPPATH (application), COREPATH (Core FuelPHP) et PKGPATH (packages) ;
- Le fichier d'initialisation de l’application est inclus : APPPATH/bootstrap.php (cf. ci-dessous pour le détail)
Étape 2, traitement / exécution : de la requête qui génère une réponse
Étape 3, affichage : de la réponse générée

Initialisation de l'application

Correspond au détail du fichier APPPATH/bootstrap.php :

Chargement de la classe Autoloader
Inclusion du fichier COREPATH/bootstrap.php de FuelPHP (en gros, le Core configure l’Autoloader pour ses propres classes)
Configuration et activaton de l’Autoloader
On définit l’environnement (développement, test / intégration, pré-prod / stage, production)
Enfin, Fuel::init() initialise l'application en fonction de l'environnement et de la configuration (fichier config.php)

Configuration du profiling et du cache
Configuration de la timezone, de l’encodage et de la locale
Configuration du base URL
Filtrage des données GPC (Get, Post et Cookie)
Active les packages, classes, config et langues à toujours charger
Chargement des routes

Traitement et exécution de la requête

L'objectif est de traiter une requête de l'internaute (appel d'une URL via son navigateur) pour lui afficher une réponse. Cette transformation est le rôle du contrôleur.

Correspond au détail de l’étape 2 (Traitement / exécution) du cheminement dans public/index.php :

Détermine le bon contrôleur en fonction des routes définies
Créé l’instance du contrôleur
Appelle sa méthode before()
Exécute l’action appropriée, qui génère la réponse
Appelle la méthode after()

Ceci peut être répétée plusieurs fois s’il y a des sous-requêtes (HMVC, nous verrons cette notion dans un article).

Configuration de l’application

FuelPHP fait partie de l’école « Configuration over convention ». En réalité, ils ont bien des conventions, mais surtout pour ce qui est bas-niveau. Cependant, la configuration est un point central ! Je crois que l’important est qu’il y a très peu de magie dans le code. Et qu'au final, il est extrêmement simple de comprendre ce que l’on fait.

Les fichiers de configuration sont stockés dans le répertoire app/config. La configuration générale de l’application se situe elle dans le fichier config.php.

En voici les options les plus importantes :

base_url : le base URL de votre site (utilisé pour générer les URL)
index_file : index.php si vous n’utilisez pas l’URL rewriting. false sinon.
profiling : activer ou non le profiler
caching : activer ou non le cache
errors.notices : faut-il afficher les notices ?
language : langue principale de votre application
language_fallback : langue de repli
locale : la locale PHP (par exemple fr_FR ou fr_CA)
encoding : encodage de votre application
default_timezone : par exemple Europe/Paris
module_paths : tableau contenant les dossiers où peuvent se situer les modules

En fonction de l’environnement (développement, test / intégration, pré-prod / stage, production) des fichiers supplémentaires de configuration peuvent être chargés.

Par exemple, pour config/config.php si l’environnement est Fuel::DEVELOPMENT et que le fichier config/development/config.php existe, il sera également chargé et les valeurs qu’il contient seront fusionnées avec celle du fichier de base (avec une priorité plus élevée).

L'installation est désormais terminée. C'est maintenant que tout commence ! À très vite pour la suite de ce tutoriel FuelPHP.

Fiche de lecture "Produire du logiciel libre"

Gilles Felix — Tue, 15 Nov 2011 14:51:00 +0100

Le logiciel libre a de quoi d�router pour les non pratiquants. M�me pour un utilisateur convaincu, tout n'est pas tr�s clair. Et le foss� est encore large pour ceux qui veulent se lancer dans la contribution ou mieux, �crire un logiciel libre.

Pour d�broussailler les in�vitables questions rien de tel qu'un bon livre. Ce billet se propose de faire un compte-rendu de la lecture r�cente d'un livre sur le logiciel libre : � Produire du logiciel libre � de Karl Fogel.

Je peux vous le dire par expérience, développer un logiciel libre, pour une entreprise habitué à la logique propriétaire, c'est n'est pas aussi simple que de publier des sources. Quelle licence choisir, quel est le modèle économique, comment appréhender la communauté, quels sont nos droits et nos devoirs ? Autant de questions qui sautent immédiatement à la figure. En cherchant à y répondre, des dizaines d'autres apparaissent, plus pointues, plus précises mais pas plus évidentes.

Heureusement dans le monde du logiciel libre, un des fondements est le partage. De code bien sûr, mais pas seulement. Partage d'expériences aussi.

Karl Fogel a été, de 2000 à 2006, manager de développement pour le logiciel Subversion chez CollabNet, Inc. En 2005, il publie un livre Producing Open Source Software - How to Run a Successful Free Software Project sous licence libre (CreativeCommons Attribution-ShareAlike). En 2010, Framasoft lance une traduction et la publie Produire du logiciel libre, toujours sous licence libre, en version papier chez InLibroVeritas et en téléchargement sur Framabook.

J'ai dévoré ce livre !!! Voici un résumé, chapitre par chapitre et à base d'extraits pour vous donner l'envie, vous aussi, de le lire.

A qui s'adresse ce livre ?

« Ce livre s'adresse aux développeurs de logiciels et aux responsables envisageant de lancer un projet Open Source, ou l'ayant déjà commencé, et qui se demandent que faire ensuite.

Nul besoin d'être programmeur, mais le lecteur devrait connaître les concepts basiques d'ingénierie logicielle tels que code source, compilateur et correctif.

Une expérience préalable du logiciel Open Source, en tant qu'utilisateur ou développeur, n'est pas nécessaire. Ceux qui ont déjà travaillé au sein d'un projet de logiciel libre trouveront certaines parties du livre évidentes et pourront les passer. Étant donné le large éventail possible d'expériences des lecteurs, j'ai essayé de nommer clairement les différentes sections et de préciser celles qui peuvent être ignorées par les familiers du sujet. »

Historique

« Le partage des logiciels est aussi ancien que les logiciels eux mêmes. Aux premiers temps des ordinateurs, les fabricants, sentant que les bénéfices économiques se trouvaient principalement dans la production de matériel, ne prêtèrent guère attention aux logiciels et leurs atouts financiers ». Les utilisateurs avaient accès aux codes sources, le modifiaient, se l'échangeaient.

« La jungle des normes matérielles a progressivement permis l'émergence de quelques lauréats grâce à une meilleure technologie, une meilleure stratégie voire la combinaison des deux. En même temps, et pas entièrement par hasard, le développement de langages de programmation dits de "haut niveau" signifiait que l'on pouvait écrire un programme une seule fois, dans un langage, et le voir automatiquement traduit (compilé) afin de fonctionner sur différents types d'ordinateurs. » La concurrence se portait alors vers les logiciels et non plus sur le matériel. C'est l'avènement du logiciel propriétaire fermé.

En 1983, Richard Stallman, ancien chercheur au MIT, lance le projet GNU et la Free Software Foundation (FSF). « En plus de travailler sur le nouveau système d'exploitation, Stallman conçut une licence dont les termes garantissent que son code restera libre à tout jamais » : La GNU General Public License (GPL) .

« Alors que le monde de l'entreprise prêtait de plus en plus attention aux logiciels libres, les programmeurs se trouvèrent confrontés à de nouveaux problèmes de représentation. L'un d'entre eux était le mot « free » lui-même. Entendant pour la première fois « free software », nombre de personnes pensaient, à tort, que cela signifiait « logiciel gratuit ». S'il est vrai que tous les logiciels libres ne coûtent rien, tous les logiciels gratuits ne sont pas libres. » ... « L'incompréhension liée au mot free était telle que les programmeurs de logiciels libres ont fini par créer une formule en réponse : « C'est free (libre) comme dans freedom (liberté), pensez à free speech (liberté de parole), pas à free beer (bière gratuite) ». »

« En 1998, le terme « Open Source » a été inventé, en tant qu'alternative à « libre », par une coalition de programmeurs devenue par la suite The Open Source Initiative (OSI). Pour l'OSI non seulement le terme « logiciel libre » était déroutant, mais le mot « libre » n'était que le symptôme d'un problème plus général : le mouvement avait besoin d'une stratégie de commercialisation pour s'adapter au monde de l'entreprise, et les discours sur les avantages moraux et sociaux du partage ne pénétreraient pas les conseils d'administration des entreprises. »

La situation actuelle

« Quand vous dirigez un projet de logiciel libre, vous n'avez pas besoin de discuter de lourds problèmes philosophiques tous les jours. Les programmeurs n'ont pas à cœur de convertir les autres participants à leurs opinions diverses (ceux qui le font se retrouvent rapidement incapables de travailler sur un projet). Mais vous devez savoir que la question "libre" contre "Open Source" existe, au moins pour éviter de dire des choses inamicales à certains des participants, mais aussi parce que comprendre les motivations des développeurs est la meilleure manière, la seule manière en un certain sens, de diriger un projet.

Le logiciel libre est une culture par choix. Pour y naviguer avec succès, vous devez comprendre pourquoi les gens ont fait le choix d'y participer en premier lieu. Les manières coercitives ne fonctionnent pas. Si les gens ne sont pas heureux au cœur d'un projet, ils vont simplement s'en écarter pour en rejoindre un autre. Le logiciel libre est remarquable, même au sein des communautés de volontaires, par la légèreté de l'investissement. La plupart des gens engagés n'ont jamais vraiment rencontrés d'autres participants face à face, et donnent simplement un peu de leur temps quand ils en ressentent l'envie. Les moyens usuels, par lesquels les humains établissent des liens entre eux et forment des groupes qui durent, sont restreints à leur plus simple expression : des mots écrits transmis par des fils électriques. À cause de cela, la formation d'un groupe soudé et dévoué peut prendre du temps. Inversement, un projet peut facilement perdre un volontaire potentiel dans les cinq premières minutes de présentation. Si un projet ne fait pas bonne impression, les nouveaux venus lui donnent rarement une seconde chance.

La brièveté, ou plutôt la brièveté potentielle, des relations est peut-être l'obstacle le plus intimidant au commencement d'un nouveau projet. Qu'est ce qui persuadera tous ces gens de rester groupés suffisamment longtemps pour produire quelque chose d'utile ? La réponse à cette question est suffisamment complexe pour être le sujet du reste de ce livre, mais si elle devait être exprimée en une seule phrase, ce serait :

"Les gens doivent sentir que leur relation à un projet, et leur influence sur celui-ci, est directement proportionnelle à leurs contributions."

Aucune catégorie de développeurs, ou de développeurs potentiels, ne devrait se sentir mise à l'écart ou être discriminée pour des raisons non-techniques. Les projets portés par une société et/ou des développeurs salariés doivent y faire particulièrement attention, le chapitre 5 aborde ce sujet plus en détail. Bien sûr, cela ne veut pas dire que, si vous ne bénéficiez pas du financement d'une société, vous n'avez à vous soucier de rien. L'argent n'est que l'un des nombreux facteurs pouvant influencer le succès d'un projet. Il y a aussi les questions de choix du langage, de la licence, du processus de développement, du type précis d'infrastructure à mettre en place, de la manière efficace de rendre publique la base du projet et bien plus encore. Commencer un projet du bon pied est le sujet du prochain chapitre. »

Bien démarrer

« La distribution du logiciel libre comporte deux facettes : elle doit trouver des utilisateurs d'une part et des développeurs de l'autre.

Ces deux besoins ne sont pas forcément antagonistes même s'ils rendent la présentation initiale du projet plus compliquée. Certaines informations sont utiles aux deux publics, d'autres le sont uniquement à l'un ou à l'autre. Les deux types d'informations devraient répondre au principe de présentation adaptée, ce qui signifie que le degré de détail présenté à chacun devrait correspondre directement à la somme de temps et d'efforts consentis par le lecteur. Un effort plus important devrait toujours être récompensé à sa juste valeur. Quand le retour sur investissement n'est pas satisfaisant, les gens peuvent rapidement perdre la foi et arrêter de s'investir.

Le corollaire en est que les apparences comptent vraiment. Les programmeurs, en particulier, sont souvent sceptiques à ce sujet. Leur amour pour le fond plutôt que pour la forme est presque une source de fierté professionnelle. Ce n'est pas un hasard si tant de programmeurs montrent de l'antipathie envers le marketing et les relations publiques, ou si les graphistes de métier sont souvent horrifiés par ce que les développeurs peuvent produire.

C'est dommage car il existe des situations - la présentation d'un projet en est une - où la forme fait partie du tout. Par exemple, l'une des premières choses que retient un visiteur à propos d'un projet est l'aspect de son site Web. Cette information est absorbée avant que le vrai contenu du site ne soit compris, avant que le texte ne soit lu ou que le visiteur ne clique sur les liens. Même si cela peut être injuste, les gens ne peuvent s'empêcher de se forger une première impression. L'apparence du site montre l'application apportée à la présentation du projet. Les humains ont des antennes très sensibles pour détecter le souci du détail. La plupart d'entre nous peuvent dire en un coup d’œil si un site Web a été assemblé à la va-vite ou s'il a été mûrement réfléchi. C'est la première information que votre projet montre et l'impression qu'elle crée pèsera, par association, sur le reste du projet. »

« Chacune des sections suivantes décrit un aspect important du commencement d'un nouveau projet. Elles sont plus ou moins présentées dans l'ordre d'apparition pour un nouveau visiteur, même si, bien sûr, votre ordonnancement peut être différent. Vous pouvez vous en servir comme d'une liste de contrôle. Quand vous commencez un projet, suivez cette liste et assurez-vous que chaque point est traité, ou au moins que vous n'aurez pas de problèmes quant aux conséquences possibles si vous décidez d'en écarter un. »

Choisissez un bon nom : parlant, simple à mémoriser, pas de confusion lors de recherche, nom de domaine disponible
Définissez clairement vos objectifs : « Une fois le site du projet trouvé, les gens chercheront une description rapide de sa teneur, votre déclaration d'intention, afin de pouvoir décider rapidement (dans les 30 secondes) s'ils souhaitent en savoir plus ou pas. Cette description devrait avoir une place de choix sur la première page, de préférence juste en-dessous du nom du projet. »
Indiquez clairement que le projet est libre
Liste des fonctionnalités et pré-requis : « si un aspect n'est pas encore finalisé, vous pouvez toujours le lister en ajoutant à côté "prévu" ou "en cours" »
Avancement du développement : « […] une page d'avancement, listant les buts du projet à court terme et ses besoins […] La page peut également fournir un historique des versions passées avec la liste de leurs fonctionnalités. Ainsi, les visiteurs peuvent se faire une idée de l'"avancement" du projet et sa vitesse de progression […] N'ayez pas peur de paraître non-préparé et ne cédez pas à la tentation d'exagérer la progression du développement. »
Téléchargements
Gestion de versions et accès au système de suivi de bogues
Les voies de communications : « Fournissez les adresses des listes de diffusion, des canaux IRC et tout autre forum où chaque personne impliquée dans le logiciel peut être jointe. Indiquez clairement que vous-même et les autres auteurs du projets sont inscrits sur ces listes de diffusion afin que les gens puissent voir qu'il existe des moyens de donner leur avis aux développeurs. Votre présence sur les listes n'implique pas que vous êtes tenu de répondre à toutes les questions ou d'intégrer toutes les suggestions. »
Les directives pour développeurs : « Si une personne envisage de contribuer au projet, elle cherchera les directives pour développeurs. Celles-ci ne sont pas vraiment techniques mais plutôt sociales : elles expliquent comment les développeurs interagissent entre eux et avec les utilisateurs, et finalement comment les choses se déroulent. »
Documentation : « La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment rapidement mettre le logiciel en route, une vue d'ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. […] Entretenir une FAQ […] Les bonnes FAQ ne sont pas écrites, elles se façonnent. Ce sont, par définition, des documents réactifs, évoluant avec le temps en réponse à l'usage quotidien des utilisateurs du logiciel […] La documentation devrait être disponible en deux endroits : en ligne, directement depuis le site Web, et dans la distribution téléchargeable du logiciel […] La documentation développeur est rédigée pour aider les programmeurs à comprendre le code et pouvoir le réparer et le compléter. Elle ne fait pas double emploi avec les directives pour les développeurs dont nous avons parlé précédemment, qui sont plus un outil social que technique. Ces consignes indiquent aux programmeurs comment bien collaborer entre eux, la documentation développeur leur indique comment se débrouiller avec le code lui-même. »
Exemples de réalisations et captures d'écran
Forges : « Quelques sites proposent un hébergement gratuit ainsi que l'infrastructure pour des projets Open Source […] En utilisant l'un de ces sites vous obtiendrez beaucoup en échange de rien. Vous tournez par contre le dos à un contrôle précis de ce que vous offrez aux utilisateurs du site. »
Choisir une licence et l'appliquer : « Une fois la licence choisie vous devriez la faire apparaître sur la première page du projet. Vous n'avez pas besoin d'ajouter le texte de la licence à cet endroit : précisez simplement le nom de la licence et créez un lien vers le texte complet se trouvant sur une autre page […] Vous annoncez ainsi au public sous quelle licence vous comptez distribuer le projet, mais ce n'est pas légalement suffisant. Pour ceci il faut que le logiciel contienne cette licence. Habituellement, le texte complet de la licence se trouve dans un fichier nommé copie ou licence, et une petite note en début de chaque fichier source indique la date du copyright, le détenteur des droits et l'emplacement du texte complet de la licence. »
Donner le ton : « Si le projet s'ouvre après des années de développement interne, son processus de développement s'en retrouvera modifié et vous devrez préparer les développeurs déjà présents à ce changement […] Les premiers pas sont les plus durs car les modèles et les attentes pour le futur n'ont pas encore été définis. La stabilité d'un projet n'est pas due à des règles formelles mais à une sagesse collective, difficile à définir, qui se développe avec le temps. […] Une fois le projet ouvert au public, vous et les autres fondateurs serez tentés de régler les problèmes délicats par des discussions privées au sein d'un cercle fermé. Tous les inconvénients des discussions publiques vous apparaîtront de manière palpable […] La tentation sera effectivement grande de prendre les décisions en petit comité et de les présenter comme des faits accomplis […] Ne le faites pas. Aussi encombrantes et lentes qu'elles puissent être, les discussions publiques seront toujours préférables sur le long terme. Prendre les décisions importantes en privé reviendrait à pulvériser du "repousse-bénévoles" sur le projet […] Tuez la vulgarité dans l’œuf […] Effectuez une inspection visible du code […] Si vous libérez un projet déjà existant, sur lequel les développeurs sont habitués à travailler dans un environnement fermé, assurez-vous que tout le monde comprenne qu'un grand changement se profile, essayez de vous mettre à leur place pour comprendre leurs sentiments […] Le meilleur moyen d'éviter ceci, est de tous les prévenir de ce qui les attend, expliquez, dites-leur que l'inconfort du début est parfaitement normal et assurez-les que les choses iront en s'améliorant. »
Annoncer : « Une fois que le projet est présentable, pas parfait, juste présentable, vous êtes prêt à l'annoncer au monde entier. C'est en fait un processus très simple : allez sur freshmeat.net (NDR maintenant http://freecode.com/) , cliquez sur « Submit » (Soumettre) en haut de la barre de navigation et remplissez un formulaire pour annoncer l'existence de votre nouveau projet. C'est sur Freshmeat que tout le monde se rend pour surveiller les annonces concernant les nouveaux projets. Vous devrez attirer l'attention de quelques paires d'yeux ici pour que le bouche à oreille à propos de votre projet commence. »

Infrastructure technique

Ce chapitre liste et décrit les infrastructures techniques nécessaires et utiles à la gestion du projet. « Prenez garde à la tentation d'automatiser les choses qui exigent vraiment une attention humaine. L'infrastructure technique est importante, mais ce qui fait fonctionner un projet Open Source, c'est l'attention et l'expression intelligente de cette attention que les humains impliqués vont déployer. Le but principal de cette organisation est de fournir à l'utilisateur les instruments les plus adaptés pour agir. »

Site Web : « La vitrine de votre projet aux yeux du public (centralisé et à sens unique). Le site Web peut également servir d'interface administrative à d'autres outils du projet. »
Listes de diffusion (avec archives publiques) : « Traditionnellement le principal moyen de communication, et aussi le plus actif, au sein du projet. C'est une bonne ressource pour garder trace des discussions. »
Contrôle de version : « Permet aux développeurs de contrôler facilement les changements apportés au code, les régressions, et de gérer les branches de développements parallèles. Il permet à chacun d'observer les modifications du code. »
Référencement de bogues : « Permet aux développeurs d'avoir à disposition l'historique de leurs travaux, de se coordonner et de planifier les correctifs. Il Permet à chacun de connaître le statut précis des bogues, et les informations liées (par exemple, les conditions de leur reproductibilité). La même méthode peut d'ailleurs être employée pour faire le suivi, non seulement des bogues, mais également des tâches, des versions, des nouvelles fonctionnalités, etc. »
Messagerie instantanée ou chat en temps réel : « Un endroit pour les discussions et les échanges sur un mode de questions - réponses énoncées rapidement et simplement. N'est pas toujours archivé complètement. »
Flux RSS pour les annonces, les suivis de bug...
Wiki éventuellement

Infrastructure sociale et politique

Ce chapitre explore la gestion sociale et politique du projet : qui dirige et comment, la méritocratie, la coopération...

En préalable : « L'ingrédient indispensable qui maintient les développeurs unis autour d'un projet de logiciel libre et les amène à faire, si nécessaire, des compromis est la "fourchabilité" du code, c'est-à-dire la possibilité offerte à chacun de prendre une copie du code source et de l'utiliser pour démarrer un projet concurrent, connu sous le nom de "fork" ou "fourche" en français […] Imaginez un roi dont les sujets pourraient à tout moment copier le royaume entier et emménager dans la copie du royaume pour le gouverner comme bon leur semble. Il est quasi certain que le règne d'un tel roi serait fort différent de celui dont les sujets sont contraints de rester sous sa loi quoi qu'il fasse. »

L'auteur identifie deux types de gestion sociale :

Les dictateurs bienveillants

« Bien que "dictateur bienveillant" soit le terme courant pour ce rôle, il vaut mieux l'imaginer comme un "arbitre approuvé par la communauté" ou un "juge". Généralement, les dictateurs bienveillants ne prennent pas concrètement toutes les décisions, ni même la plupart. Il est peu probable qu'une seule personne puisse avoir les compétences requises dans tous les domaines d'un projet et, de toutes façons, les bons développeurs ne s'éterniseront pas s'ils n'ont pas quelque influence sur la direction du projet. C'est pourquoi les dictateurs bienveillants ne dictent généralement pas grand-chose. En revanche, ils laissent les choses s'éclaircir d'elles-mêmes au cours de la discussion et de l'expérimentation, quand c'est possible. Ils y participent eux-mêmes, mais en tant que simples développeurs, s'en remettent souvent à un responsable du domaine ayant plus de savoir faire. C'est seulement quand il apparaît clairement qu'un consensus ne peut être trouvé et que la majorité veut que quelqu'un prenne une décision afin que le développement puisse continuer, qu'il tape du poing sur la table en disant : "Voilà ce qu'il faut faire." »

La démocratie basée sur le consensus

« En vieillissant, les projets tendent à s'éloigner du modèle du dictateur bienveillant au profit de systèmes plus ouvertement démocratiques. »

« Quand le consensus n'est pas possible, votez […] Le plus difficile, en ce qui concerne le vote, est de déterminer quand il doit avoir lieu […] Un système de vote c'est bien, mais qui a le droit de vote ? C'est là une question potentiellement sensible, car elle oblige le projet à distinguer certaines personnes selon leur implication ou leur jugement. La meilleure solution consiste à utiliser une distinction existante, comme l'accès à la validation ("accès de commit"), et à y attacher les privilèges du vote »

« Arrivé à un certain point, le nombre de conventions et d'accords tacites entourant votre projet risque de devenir si important qu'il deviendra nécessaire de les consigner quelque part »

L'argent

Ce chapitre aborde la question du financement d'un projet de logiciel libre. Il ne concerne pas uniquement les développeurs payés pour travailler sur des projets de logiciel libre, mais aussi leurs responsables, qui doivent comprendre les règles sociales régissant le cadre du développement.

« Si vous dirigez des programmeurs dans un projet Open Source, faites en sorte qu'ils participent au projet assez longtemps pour acquérir l'expertise technique et politique nécessaire, deux ans au minimum […] La crédibilité acquise ne peut être transférée »

« Vos développeurs feront leur possible pour s'exprimer, sur les forums publics de développement, en tant que participants individuels plutôt que comme représentants d'une entreprise monolithique. Ce n'est pas que la présence massive d'une entreprise ait une connotation négative (enfin, c'est possible, mais ce n'est pas le sujet de ce livre). C'est plutôt parce que les projets Open Source ne sont structurellement équipés que pour traiter avec des entités individuelles. »

« Annoncez les buts de votre organisation en toute transparence, sans révéler de secrets commerciaux. Si vous voulez que le projet incorpore une certaine fonctionnalité parce que, par exemple, vos clients la réclament à cor et à cri, annoncez-le clairement sur les listes de diffusion. Si les clients souhaitent rester anonymes, comme c'est parfois le cas, demandez-leur au moins si vous pouvez les citer comme exemples sans les nommer. Les développeurs accepteront d'autant mieux vos propositions qu'ils en connaîtront les raisons. »

« Mais la programmation n'est la seule activité au sein d'un projet Open Source, loin s'en faut. Du point de vue des volontaires du projet, c'est la partie la plus visible et la plus glamour. Ce qui veut malheureusement dire que les autres activités, comme la documentation ou les tests formels par exemple, peuvent parfois être négligés, comparés à l'attention qu'ils reçoivent dans les logiciels propriétaires en tout cas. Les entreprises arrivent parfois à compenser cette lacune en assignant une partie de leur infrastructure de développement de logiciel interne à des projets Open Source. » Ce conseil s'applique aux tests, au côté juridique, à la documentation, l'hébergement...

« Afin de conserver la communauté de développeurs bénévoles de votre côté, il est très important de ne rien dire qui ne soit vérifiable. Contrôlez scrupuleusement toutes vos affirmations et donnez au public les moyens de les vérifier de son côté. La vérification indépendante et rapide compose une grande partie du domaine de l'Open Source et cela s'applique au-delà du code. »

« Abstenez-vous de critiquer les logiciels Open Source concurrents. Vous pouvez tout à fait exposer des faits négatifs, c'est-à-dire des affirmations facilement vérifiables, comme c'est souvent le cas dans les bons tableaux comparatifs. Mais il y a deux raisons pour lesquelles il vaut mieux éviter toute légèreté lorsqu'on diffuse des critiques négatives. Premièrement, elles sont susceptibles d'initier une guerre malsaine qui éloigne des discussions productives. Et surtout, deuxièmement, il se peut que certains développeurs volontaires de votre projet travaillent également sur le projet concurrent. »

Communication

« La capacité à écrire avec clarté est peut-être la qualité la plus importante que l'on puisse avoir dans un environnement Open Source. Sur le long terme, elle compte davantage que les compétences en programmation. S'il a des difficultés à communiquer, un programmeur aura beau être génial, il ne pourra s'occuper que d'une chose à la fois, et il n'est même pas certain d'obtenir l'attention désirée. »

« C'est un fait : sur Internet on ne vous connaît qu'au travers de vos écrits ou de ce que l'on écrit sur vous. »

« Après avoir écrit des milliers de messages, vous observerez sûrement une simplification de votre style. Cela semble être la norme dans la plupart des forums techniques, et intrinsèquement, il n'y a rien de mal à cela. Un degré de simplification inacceptable pour des interactions sociales habituelles est simplement la norme des hackers de logiciels libres. »

« Quand vous participez à un projet en ligne vous serez tenté de répondre à tout, c'est l'un des pièges classiques. Ne le faites pas. Tout d'abord, il risque d'y avoir plus de fils de discussions que vous ne pouvez en suivre, en tout cas une fois que le projet se sera développé. »

« Dans une liste de discussion animée, il y a deux impératifs. Le premier, évidemment, consiste à distinguer ce qui mérite votre attention de ce que vous pouvez ignorer. L'autre consiste à agir de manière à ne pas créer de bruit : vous voulez non seulement que vos propres messages soient pertinents, mais aussi qu'ils incitent les autres à en poster d'aussi pertinents ou bien à s'abstenir. »

« La probabilité de dérive n'est nulle pour aucun fil, mais les sujets techniques simples sont un terreau très propice à l'égarement. Après tout, les sujets techniquement complexes ne seront bien compris que par une faible proportion de participants, certainement les développeurs les plus expérimentés ayant déjà pris part à ce genre de discussions des milliers de fois, et qui savent comment aboutir à un consensus viable pour tous. »

« Éviter les trolls »

« Traditionnellement, toutes les communications échangées dans un projet Open Source (exceptées parfois les conversations IRC) sont archivées. Les archives sont publiques, consultables et ont une stabilité référentielle : c'est-à-dire qu'une information enregistrée a une adresse donnée où elle reste pour toujours. Utilisez ces archives autant que possible et aussi visiblement que possible. Même si vous connaissez par coeur la réponse à une question, si vous pensez qu'il y a dans les archives une référence qui contient la réponse, prenez le temps d'aller la chercher et de la montrer. Chaque fois que vous faites ceci publiquement et de manière visible, quelqu'un apprend pour la première fois que les archives sont là et qu'elles contiennent des réponses aux questions. »

« Pas de discussion dans le système de suivi de bogues »

Faille de sécurité

Une partie très riche en exemples.

« La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'ensuit et le correctif. »

« Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue. Concocter un correctif aussi rapidement que possible, surtout si c'est quelqu'un d'étranger au projet qui a rapporté le bogue, parce qu'alors vous savez qu'au moins une personne en dehors du projet est capable d'exploiter la vulnérabilité. »

Paquets, sorties et développement quotidien

Un chapitre très technique sur la numérotation des versions, l'utilisation des branches de publication, le format de livraison, le changelog, la maintenance de plusieurs versions, la planification des publications

Est évoqué également le processus de décision sur ce qui est inclus dans une version.

Encadrer les volontaires

Comme son titre l'indique ce chapitre fait le tour de la question de l'encadrement des volontaires :

délégation
félicitations et critiques
partage des taches
choix des commiters
responsabilisation (correctif, traduction, documentation, FAQ)
gestion d'un fork

Licences, droits d'auteur et brevets

Ce chapitre commence par un glossaire des termes suivants :

Logiciel libre
Logiciel Open Source
Conforme au DFSG - Conforme au contrat social Debian
Approuvé OSI - Approuvé par l'Open Source Initiative
Propriétaire, source fermée
Domaine public
Copyleft

Il explique ensuite les différents aspects différenciant les licences :

Compatibilité avec les licences propriétaires
Compatibilité avec d'autres licences libres
L'obligation de crédit
La protection de marques déposées
La protection de l'"intégrité artistique"

GPL

« Les licences peuvent être regroupées en deux grandes catégories selon qu'elles sont ou non compatibles avec les licences propriétaires.

On distingue donc la Licence Publique Générale GNU de toutes les autres licences. Parce que l'objectif premier des auteurs de la GPL est la promotion du logiciel libre, ils créèrent délibérément la licence de façon à ce qu'il soit impossible d'intégrer du code sous GPL au sein de programmes propriétaires. En particulier, parmi les conditions de la GPL, on retrouve ces deux dispositions :

Tout logiciel dérivé, tout logiciel contenant une quantité significative de code sous GPL doit être distribué lui-même sous GPL.
Aucune restriction additionnelle ne peut être placée sur la redistribution du logiciel original ou dérivé.

Avec ces conditions, la GPL parvient à fabriquer une liberté contagieuse. Une fois qu'un programme est licencié sous GPL, ses termes de redistribution sont viraux, ils se transmettent à tout autre contenu intégrant ce code. L'emploi de code sous GPL dans un programme fermé est donc strictement impossible. Cependant, ces mêmes clauses rendent aussi la GPL incompatible avec certaines autres licences libres. C'est typiquement le cas des licences imposant une exigence supplémentaire comme, par exemple, une clause de crédit. L'incompatibilité avec la GPL est flagrante puisque cette dernière stipule que "Vous ne pouvez pas imposer de nouvelles restrictions.". Du point de vue de la Free Software Foundation, ces effets secondaires sont recherchés, ou en tout cas, ils ne sont pas regrettables. Non seulement la GPL assure la liberté de votre logiciel, mais elle en fait aussi un agent poussant les autres logiciels à devenir libres. »

La GNU Affero GPL : une version de la GNU GPL pour le code côté serveur: En 2007, la Free Software Foundation a publié une variante de la GPL appelée GNU Affero GPL*. Elle a été créée pour appliquer les mêmes clauses de partage introduites par la GPL aux entreprises, de plus en plus nombreuses, qui proposent des services distants, des logiciels qui fonctionnent sur leurs serveurs, des logiciels avec lesquels les utilisateurs n'interagissent qu'en ligne et qui ne sont donc jamais distribués aux utilisateurs sous forme de code source ou d'exécutable. Un grand nombre de ces services employaient des logiciels sous GPL, souvent après y avoir apporté des modifications, et pourtant ils n'avaient pas à partager ces modifications puisque le code n'était pas distribué. La parade de la licence GNU AGPLv3 consiste donc simplement à ajouter à la GPL classique une clause pour les "Interactions à distance" indiquant que "… si vous modifiez le Programme, votre version modifiée doit offrir de manière visible à tous les utilisateurs interagissant à distance grâce à un réseau informatique… la possibilité de recevoir la Source Correspondante de votre version… gratuitement, grâce aux méthodes standard ou habituelles de copies de logiciel". Les règles établies par la GPL sont ainsi applicables dans le nouveau monde de la fourniture de services d'applications. »

Attribution des droits d'auteur et propriété

« La gestion des droits d'auteur sur un code libre, fruit du travail de plusieurs personnes, est une question qu'il vous faudra résoudre. Trois options s'offrent à vous. La première consiste à purement et simplement ignorer le problème du droit d'auteur (je vous le déconseille). La deuxième est de demander un Accord de Licence du Participant (ALP) à chaque personne travaillant sur le projet, accordant explicitement au projet le droit d'utiliser le code du participant. C'est en général suffisant pour la plupart des projets, le point positif étant que dans certaines juridictions ces ALP peuvent être envoyés par courrier électronique. La troisième possibilité est d'obtenir des participants l'attribution complète des droits d'auteur afin que le projet (c'est-à-dire une personne morale, généralement à but non lucratif) concentre tous les droits d'auteur. C'est la voie la plus sûre légalement, mais aussi la plus contraignante pour les participants, seuls quelques projets l'empruntent.

Notez que même si la propriété intellectuelle est centralisée, le code demeure libre car les licences Open Source ne donnent pas au détenteur des droits la possibilité de rendre rétroactivement propriétaires toutes les copies de ce code. Donc, même si le projet, en tant que personne morale, retourne soudainement sa veste, et décide de distribuer le code sous une licence plus restrictive, cela ne posera pas de problème à la communauté. Les autres développeurs n'auraient qu'à initier une fourche basée sur la dernière version libre du code, et continuer comme si de rien n'était. Cette possibilité existant, la plupart des participants coopèrent lorsqu'on leur demande de signer un ALP ou une attribution de droit d'auteur. »

Quelques exemples d'ALP :

ALP pour les participants individuels :

ALP pour les entreprises participantes :

La double licence

« Certains projets tentent de s'auto-financer en adoptant une double licence, c'est un système par lequel toute société peut payer le détenteur des droits d'auteur et obtenir son accord pour utiliser le code dans un programme propriétaire, le code restant libre pour les projets Open Source. Les librairies de code se prêtent évidemment mieux à cette double licence que des applications autonomes. Les termes exacts varient d'un cas à l'autre. La licence pour l'aspect libre est la GNU GPL, puisqu'elle empêche déjà n'importe qui d'ajouter le code protégé dans un produit propriétaire sans l'autorisation du détenteur des droits, parfois, c'est une licence personnalisée ayant les mêmes effets. Ainsi la licence MySQL utilise la licence GNU GPL, on peut aussi citer comme exemple de licence personnalisée le système de licence de Sleepycat Software.

Vous vous demandez sûrement comment le détenteur des droits peut proposer une licence propriétaire contre rémunération si les termes de la GNU GPL stipulent que le code doit être mis à disposition sous des conditions moins restrictives. Les termes de la GPL sont imposés par le détenteur des droits à tout le monde sauf aux logiciels propriétaires, l'auteur est libre de décider de ne pas s'imposer les mêmes termes. Imaginez que le détenteur des droits possède un nombre infini de copies du logiciel rangées dans un seau, à chaque fois qu'il sort une copie du seau pour la donner au monde, il peut décider quelle licence appliquer : GPL, propriétaire ou autre. Ce n'est pas la GPL ou une quelconque autre licence Open Source qui lui donne ce droit, ce sont les lois du droit d'auteur.

Dans le meilleur des cas, la double licence permet ainsi au projet de logiciel libre de s'assurer une source de revenus stable. Malheureusement, la dynamique normale d'un projet Open Source peut s'en retrouver altérée. Le problème est que chaque volontaire apportant sa contribution au code participe maintenant aux deux entités : la fois à la version libre et à la version propriétaire du code. Contribuer à la version libre ne lui posera certainement pas problème, c'est la norme dans les projets Open Source, mais par contre, participer à la création de revenus semi-propriétaires au bénéfice de tiers lui conviendra peut-être moins. C'est d'autant plus vrai que, pour une double licence, les participants doivent céder leurs droits au projet par une déclaration écrite. Le projet doit se couvrir au cas où un participant mécontent prétendrait à un pourcentage sur les revenus propriétaires. À partir du moment où les participants signent cette attribution des droits, ils ne peuvent plus ignorer que leur production enrichira une autre personne.

Tous les volontaires ne se soucieront pas de cela, après tout, leur contribution participe également au développement de l'édition Open Source, et c'est bien là leur intérêt. Néanmoins, la double licence est un exemple où le propriétaire des droits d'auteur se donne à lui-même un droit particulier que les autres personnes du projet n'ont pas, ce qui conduira tôt ou tard à des tensions, du moins avec quelques volontaires.

En pratique, il semble que les entreprises développant des logiciels à double licence n'ont pas une communauté de développement vraiment égalitaire. Ils profitent de correctifs de bogues mineurs ou de petits travaux de bénévoles, mais font le gros du travail en interne. Par exemple, Zack Urlocker, vice président du marketing chez MySQL, m'a confié que l'entreprise finit souvent pas employer les volontaires les plus actifs de toute façon. Ainsi, le produit en lui même est Open Source, sous licence GPL. Son développement est plus ou moins contrôlé par une entreprise, même si la possibilité d'initier une fourche en cas de profond désaccord existe (elle reste extrêmement faible cependant). Je ne sais pas comment cette menace affecte la politique de l'entreprise, mais en tout cas, MySQL ne semble pas avoir de problème d'acceptation, que ce soit dans le monde de l'Open Source ou ailleurs. »

Quel framework choisir ? Nous votons FuelPHP

Julian Esp�rat — Mon, 14 Nov 2011 14:33:00 +0100

Chaque jour am�ne son lot de nouveaux frameworks. Comment faire son choix devant cette offre pl�thorique ? Voil� la question que nous nous sommes pos�s au printemps dernier. Apr�s des �tudes et tests, nous avons finalement choisi un petit nouveau, FuelPHP. Cela fait maintenant six mois et nous ne l'avons pas regrett� depuis. Voici pourquoi.

Sommaire du tutoriel
Développer sous FuelPHP

FuelPHP est le petit nouveau (la version 1.0 finale est sortie le 31 juillet 2011) qui commence à se faire un nom dans le monde PHP. Basé sur le HMVC, il ne fonctionne qu’à partir de PHP 5.3 et rassemble des bonnes idées de plusieurs autres frameworks connus :

Tout comme CodeIgniter, FuelPHP se veut léger et rapide, facile à apprendre et a peu de dépendances niveau serveur.

Tout comme Kohana, FuelPHP hiérarchise l'accès aux fichiers et possède un excellent Query Builder (générateur de requêtes SQL).

Tout comme Symfony, FuelPHP possède une ligne de commande, un outil de migration, un ORM et un système de templates.

On y trouvera également des inspirations de Ruby On Rails ou encore de CakePHP.

Je ne vais pas vous faire la liste complète des fonctionnalités, mais il faut savoir que malgré sa jeunesse, FuelPHP inclut déjà nativement énormément d’éléments. Outre tout ce que je viens déjà de citer, on y trouve aussi la gestion de la sécurité, les ACL, tous les moteurs de templates populaires (Mustache, Markdown, Smarty, Twig, Haml, Jade, Dwoo), la validation des formulaires, le REST, le scaffolding, l'envoi de mails, et j’en passe…

Simplicité de prise en main

À titre personnel j’ai été très enchanté par FuelPHP. Ayant déjà essayé d’autres gros calibre (Zend ou Symfony pour ne pas les citer), le coût à l’entrée est relativement important et il faut vraiment s’accrocher pour réussir à faire quelque chose. Au contraire, FuelPHP est vraiment très facile à prendre en main et on voit tout de suite le résultat de notre travail. On écrit peu de code et on comprend ce qui se passe !

Ok, mon discours est évangéliste, mais l’introduction doit bien vous faire envie de lire la suite, non ?

Pensé pour les développeurs

Tiré de la documentation officielle : "[...] FuelPHP est né de la frustration des développeurs avec les frameworks actuels. [...] Il tire sa fierté de sa syntaxe claire.". Le ton est donné !

Effectivement, FuelPHP est basé sur une approche pragmatique : il faut que ça soit simple pour le développeur. L’exemple qui suit (qui fera peut-être hérisser les poils sur la tête des puristes) permet de se faire une idée :

Les namespaces constituent un point central. Le cœur de FuelPHP a son propre namespace Fuel\Core. Les classes qu’il contient sont automatiquement aliasées au namespace global, quand elles sont appelées depuis ce dernier et qu’elles n’y existent pas déjà.

Concrètement c’est un jeu d’enfant à l’utilisation : pour accéder à la classe Controller fournie par le framework (et définie dans le namespace Fuel\Core), on accède simplement à la classe globale \Controller ! C’est rapide à écrire et très facile à retenir ! Dois-je préciser que dans Symfony, l’accès à cette même classe se fait via Symfony\Bundle\FrameworkBundle\Controller\Controller ? ;-)

Et on peut ainsi étendre voire même remplacer n’importe quelle classe de Fuel\Core en la définissant dans le namespace global.

Pour les packages et les modules (nous verrons un peu plus tard ce que c’est), la convention est tout aussi enfantine : pas de nom à rallonge ! Chacun utilise un espace de nom simple (à un seul niveau) correspondant à son nom.

Alors, ça vous donne envie ? Passons à l'installation.

Facebook par iA, notre test grandeur nature

Antoine Lefeuvre — Thu, 10 Nov 2011 14:18:00 +0100

Il y a des designs qui marquent. Et par design, j'entends la d�finition de Steve Jobs. Certains ont �t� marqu�s par le presse-agrume de Starck, d'autres par l'iPod ou, plus r�cemment, par Flipboard.

�tonnamment, l'un des designs qui m'a le plus marqu� n'a jamais pass� le stade du prototype. Enfin, jusqu'il y a peu. Chez Novius, nous l'avons fait passer � l'�tape suivante.

Three-pane interface

Fin 2006, début 2007, l'agence de design interactif Information Architects était en contact avec Facebook. L'objectif n'était ni plus ni moins que de reconcevoir, de redesigner le réseau social. Le projet n'aboutit pas. Fort heureusement, en mars de l'année dernière, iA décida de publier le travail réalisé. Seul l'habillage graphique fut remis au goût du jour, le concept derrière l'interface ne bougea pas :

C'était la première foi, à ma connaissance, qu'une three-pane interface était utilisée pour un réseau social. Une three-paquoi ? L'interface à trois volets, en bon français, est un standard pour les logiciels de messagerie. Même Google, pourtant farouchement décidé à ré-inventer l'UX email avec Gmail, l'a finalement adopté.

Le principe de cette interface est le suivant : trois volets liés entre eux et organisés de manière hiérarchique (Dossiers > Emails > Détails).

Dans le cas de Facebook par iA, il s'agit de trois volets verticaux, ce qui accentue la hiérarchisation du contenu. De gauche à droite, on trouve ainsi Filtres > Flux d'informations > Réactions.

Détail intéressant : l'architecture de l'information est directement visible dans l'UI.

Faire converger les communications

Quel intérêt y a-t-il à utiliser l'interface traditionnelle de l'email pour un réseau social ? Oliver Reichenstein de iA cite, entre autres, les avantages suivants :

Il y a plus de place pour le flux
Il y a plus de place pour la discussion
Les éléments principaux de navigation sont regroupés
La colonne de droite n'est pas le bazar habituel

Mais, ce qui nous a surtout séduit au moment de concevoir Réso-Nova (notre solution pour réseaux sociaux d'entreprise, RSE, et communautés de marque), c'est le lien fort entre email et réseau social, à l'origine même de ce design ("Our basic idea, to create an mail-application like interface", Oliver Reichenstein). Dans le contexte actuel d'infobésité, l'utilisateur souffre de la multiplication des outils de communication : Où est le document ? Dans la knowledge base. Et l'explication associée ? Je te l'ai envoyée par email. Qu'en pense Victor ? Il a répondu sur Facebook.

Notre objectif avec Réso-Nova est de faire converger les conversations d'une communauté vers un outil central. Or, un premier pas dans cette direction est d'adopter une interface qui conviennent aux adeptes de l'email comme aux inconditionnels des réseaux sociaux.

De plus, nous cherchons à doter notre utilisateur d'un outil de lutte contre l'infobésité. Or, le flux facebookien est plus long à parcourir, les réactions y étant intégrées. C'est la double peine de l'information non pertinente : non seulement l'utilisateur la voit apparaitre dans son flux, mais elle / il est obligé(e) de passer les réactions avant d'arriver à l'information suivante. Dans un flux comme celui imaginé par iA, on choisit de déporter son regard sur la droite pour lire les commentaires. Le parcours rapide du flux est alors possible, de la même manière qu'on filtre ses emails à partir de la boite de réception avant d'afficher le détail de certains.

Enfin, nous avons bâti Réso-Nova autour de groupes thématiques. Notre architecture d'information est claire et colle parfaitement à celle de Facebook par iA : Groupes thématiques > Flux > Réactions.

J'entends des voix qui s'élèvent pour dire : Twitter a déjà adopté ce type d'interface ! En effet, la dernière interface, dite New Twitter, ainsi que Twitter pour iPad ont été inspirés par le travail d'iA. Néanmoins, le choix a été fait sur le web de n'avoir que deux volets (sur iPad, la fine colonne de gauche s'apparente au volet de filtres). De plus, la structure de l'information de Twitter est bien particulière. Les tweets sont limités à 140 caractères et beaucoup de réactions prennent la forme de retweets. Ainsi, le volet de droite renvoie souvent des meta-données (liens vers les utilisateurs cités, utilisateurs ayant retweeté, etc.), plutôt que d'afficher une conversation. A tel point que le formulaire de réaction n'y est pas présent. C'est le même lien que celui présent sous le tweet et qui ouvre une pop-up.

Je pense donc que Réso-Nova est une mise à l'épreuve du concept de iA plus fidèle, mais peut-être me trompé-je ?

4 mois plus tard

Voilà quatre mois maintenant que la beta de Réso-Nova motorise notre réseau social interne. Pendant cette période, 1500 contributions ont été publiées générant plus de 4000 commentaires, pour l'entreprise de 35 personnes qu'est Novius. Nous n'avons pas mené d'A/B testing pour comparer l'efficacité de notre flux iA à un flux facebookien classique. 35 utilisateurs, c'est bien peu pour une étude quantitative. Par contre, notre proximité avec les utilisateurs, nos collègues, nous permet de vous livrer cette analyse qualitative.

Ce qui a posé problème

L'aspect le plus problématique de ce design est l'adoption. Réunir email et réseau social dans une même interface est forcément un compromis, un entre-deux. Ceux à qui on présente un réseau social d'entreprise s'attende à trouver un réseau social, c'est-à-dire Facebook. Le lien avec la three-pane interface de l'email est rarement fait, les trois colonnes ressemblant finalement assez peu à Outlook. L'utilisateur n'est donc pas dans un environnement familier et la prise en main de l'outil s'en ressent.

Ce qui a fonctionné

Ce design est un fantastique appel à la réaction. Pour une résolution de 900px de haut, on affiche quatre contributions et autant de formulaires pour commenter. Réagir n'a jamais été aussi facile et rapide. En octobre, la moyenne de commentaires par utilisateur a été de 34. Et c'est sans compter les +1, que nous avons voulu très en avant, à la manière d'un digg-like.

Points de design

Je continue à m'interroger sur plusieurs points concernant ce design. La gestion du lu / non lu, par exemple, s'est révélée compliquée. Faut-il un système à la Google Reader qui enregistre les lus au-fur-et-à-mesure du parcours du flux, sans autre action de l'utilisateur que le scroll ? Ou alors limiter le flux aux seuls sujets à l'image des emails pour obliger l'utilisateur à cliquer pour lire ? Pour le moment, nous avons décidé que seules les actions conscientes de l'utilisateur déclenchent le lu : nouveau commentaire, +1, ouverture d'une pièce jointe, visionnage de tous les commentaires, etc. Malgré cela, pour de nombreux utilisateurs, les non lus s'accumulent de manière anormale. La solution est-elle dans plus d'automatisation ? C'est à tester.

Autre question en suspens, la hauteur des items du flux. Contrairement à Twitter, les informations publiées sur Réso-Nova sont à géométrie variable, du message court semblable à un tweet à un long article pareil à celui que vous êtes en train de lire. Pour ne pas empêcher le parcours rapide du flux, la hauteur des items est fixe. C'est donc un résumé, une information tronquée qui est affichée par défaut dans le flux. Il faut alors ouvrir l'information pour la voir en entier (c'est la même action qui affiche tous les commentaires). Or, certains utilisateurs préféreraient ne pas avoir tant à ouvrir et fermer les informations, et que la hauteur réflète mieux la longueur. De nouveau, des tests s'imposent.

Dernier point, l'ordre des commentaires. Quand l'information est résumée, les derniers commentaires et le formulaire de réaction se trouvent directement à côté.

Par contre, dès que l'information est ouverte, les voici tout en bas. L'ouverture provoque donc une saute, qui n'est pas des plus ergonomiques.

Une solution serait un affichage antichronologique des commentaires, mais le remède ne serait-il pas pire que le mal ?

Vous l'aurez compris, il nous faut encore itérer et itérer pour affiner ce design. Malgré les points bloquants ou sans réponse, je reste un fervent partisan du travail d'iA. Et pas simplement comme designer ; Antoine l'utilisateur a publié 200 commentaires le mois dernier.

D�velopper un plugin jQuery UI : h�ritage

Gilles Felix — Mon, 05 Sep 2011 14:42:00 +0200

En cinq chapitres, nous avons appris � d�velopper un plugin jQuery UI. J'esp�re que, comme moi, vous avez �t� convaincus par l'architecture de widget mise � disposition par le framework jQuery UI.
Personnellement c'est le chapitre d'aujourd'hui qui m'a le plus attir� dans la d�marche jQuery UI : la possibilit� d'�tendre facilement un widget.

Sommaire du tutoriel
Développer un plugin jQuery UI

Le développement Javascript utilise encore trop peu les concepts de développement Objet. L'explosion des sites interactifs, déportant la complexité du développement du serveur vers le navigateur, est assez récente. Le Javascript embarqué dans les pages se limitait, il y a encore quelques années, à quelques fonctions pour valider les formulaires et deux / trois autres, toutes faites, pour gérer du rollover. Les bonnes pratiques du développement Javascript émergent petit à petit, comme pour tout langage informatique. Il faut reconnaître également qu'en Javascript "de base", créer et manipuler des objets est tout sauf intuitif, y compris (et surtout ?) pour un développeur maîtrisant cette technique dans un autre langage.

Il existe quelques frameworks Javascript facilitant le codage en Objet. Pour parler franchement je n'en ai testé aucun : quand je code du Javascript en Objet, je réinvente la roue à chaque fois. Jusqu'à ce que je lise ce tutorial jQuery dont je vous ai parlé au premier chapitre. À l'époque je cherchais un plugin jQuery du type "popup DHTML". J'aimais bien le widget Dialog de jQuery UI mais il lui manquait quelques fonctionnalités dont j'avais absolument besoin. A + B = BAnco, et si j'étendais le widget Dialog pour lui ajouter les fonctionnalités qui me manquaient.

Au final, mon projet a changé de direction et je n'ai pas eu besoin de mon widget Dialog étendu. Mais j'ai gardé l'habitude de coder mes widgets en jQuery UI et je ne le regrette pas. Aujourd'hui je développe une interface type navigateur avec une barre d'onglets bourrée de fonctionnalités, et bien entendu je suis parti du widget Tabs de jQuery UI.

Quand est-ce qu'on revoit du code ?

Mais assez causé. Revenons à notre exemple. Mettons-nous dans la peau d'un développeur qui est prêt à utiliser notre widget mais qui aimerait bien lui ajouter un petit plus non prévu.

Notre plugin encapsule un élément, lui ajoute un titre et permet d'ouvrir / fermer le bloc. Notre développeur aimerait ajouter une petite poignée en bas du bloc pour rendre l'ouverture / fermeture plus intuitive.

Commençons par étendre notre widget initial.

// Notre nouveau widget s'appelle blocextend
// Le second param�tre est notre widget bloc initial
// Le troisi�me param�tre contient le JSON qui va �tendre l'objet bloc initial
// Toute fonction ou option non red�finie sera identique � la version de bloc
$.widget ('demo.blocextend', $.demo.bloc, {
});

Ajoutons notre petite poignée via une redéfinition de la méthode _create.

_create: function() {
    var self  = this;

    // On appelle la m�thode _create du widget bloc initial
    $.demo.bloc.prototype._create.call(this);

    // Notre poign�e est un simple lien
    this.uiBlocHandle = $('<a href="#"></a>')
        // La classe ui-bloc-handle nous permettra de positionner correctement la poign�e
        .addClass('ui-bloc-handle ui-corner-all ui-state-default')
        // Ajout d'effets visuels d'interaction par les classes CSS d'�tat de jQuery UI
        .hover(function() {
            self.uiBlocHandle.addClass('ui-state-hover');
        }, function() {
            self.uiBlocHandle.removeClass('ui-state-hover');
        })
        .focus(function() {
            self.uiBlocHandle.addClass('ui-state-focus');
        })
        .blur(function() {
            self.uiBlocHandle.removeClass('ui-state-focus');
        })
        // On ajoute la poign�e au container de widget cr�� dans le bloc initial
        .appendTo(self.uiBlocContainer);

    // Notre poign�e contient un SPAN
    this.uiBlocHandleText = $('<span></span>')
        // Le SPAN sera une ic�ne en forme de chevron orient� vers le Nord (ui-icon-carat-1-n)
        // Voir la page du themeroller de jQuery UI : http://jqueryui.com/themeroller/
        .addClass('ui-icon ui-icon-carat-1-n')
        // Le texte par d�faut de notre poign�e
        .text('Ouvrir le bloc')
        // On ajoute le SPAN � la poign�e
        .appendTo(self.uiBlocHandle);
},

Ajoutons un comportement à notre poignée via la méthode _init − pour comprendre la différence en _create et _init, voir le chapitre fonctionnalités avancées.

_init : function() {
    var self = this;

    // On appelle la m�thode _init du widget bloc initial
    $.demo.bloc.prototype._init.call(this);

    // On enl�ve tous les �v�nements click de la poign�e
    // En cas de r�initialisation, cela �vite d'ajouter un nouvel �v�nement click
    // � notre poign�e qui en a d�j� potentiellement un
    self.uiBlocHandle.unbind('click');

    if (self.options.togglable) {
        // Notre bloc est fermable
        // On ajoute l'�v�nement click � la poign�e qui se contente de d�clencher le click sur le titre
        self.uiBlocHandle.click(function(event) {
            self.uiBlocTitle.click();
        }).show(); // On affiche la poign�e
    } else {
        // Le bloc n'est pas fermable, on cache la poign�e
        self.uiBlocHandle.hide();
    }
},

Pour finir modifions les méthodes _open et _close pour ajuster le look de notre poignée en fonction de l'état du bloc.

_close: function() {
    var self = this;

    // On appelle la m�thode _close du widget bloc initial
    $.demo.bloc.prototype._close.call(this);

    if (self.options.togglable) {
        // Notre bloc est fermable
        // On affiche la poign�e qui a �t� cach�e par la m�thode _close du bloc initial
        self.uiBlocHandle.show();
    }

    // L'ic�ne de la poign�e devient un chevron orient� vers le sud
    // On change aussi le texte
    this.uiBlocHandleText.removeClass('ui-icon-carat-1-n').addClass('ui-icon-carat-1-s').text('Ouvrir le bloc');
},

_open: function() {
    var self = this;

    // On appelle la m�thode _open du widget bloc initial
    $.demo.bloc.prototype._open.call(this);

    // L'ic�ne de la poign�e devient un chevron orient� vers le nord
    // On change aussi le texte
    this.uiBlocHandleText.removeClass('ui-icon-carat-1-s').addClass('ui-icon-carat-1-n').text('Fermer le bloc');
}

Un peu de CSS tout de même

Notre poignée est pour l'instant un simple lien à la fin du container de notre bloc. On va la positionner de façon à ce qu'elle apparaisse à cheval sur le bord inférieur du bloc, au milieu de la largeur.

/* CSS du widget blocextend pour positionner la poign�e */
.ui-bloc {
    /* le bloc est pass� en position relative pour pouvoir positionner la poign�e � l'int�rieur en absolu */
    position: relative;
}
.ui-bloc .ui-bloc-handle {
    /* La poign�e est positionn�e en absolu par rapport � son container */
    position: absolute;
    right: 50%; /* Elle s'affiche au milieu de la largeur du bloc */
    bottom: 0; /* Elle s'affiche en bas du bloc */
    margin: 0 -10px -10px 0; /* On d�cale les margin droit et bas de 10 pixels pour l'effet "A cheval" sur la bordure */
}

Elle est pas belle ma poignée ?

D�velopper un plugin jQuery UI : fonctionnalit�s avanc�es

Gilles Felix — Wed, 24 Aug 2011 10:37:00 +0200

Les 4 premiers chapitres nous ont permis de faire le tour des fonctionnalit�s principales du framework de cr�ation de widgets jQuery UI. Voyons aujourd'hui les fonctionnalit�s avanc�es.

Sommaire du tutoriel
Développer un plugin jQuery UI

Le prototype pour widgets jQuery UI implémente par défaut plusieurs méthodes qui ont vocation à être étendues. Libre à vous de les implémenter ou non. Nous avons déjà vu la méthode _create, mieux vaut l'implémenter sans quoi notre widget ne ferait pas grand chose. Mais il y a aussi _init, destroy, enable, disable et option (les descriptions qui suivent sont fortement inspirées de la documentation jQuery UI) :

_init() : Peut facilement être confondu avec _create. À la création d'un widget, _create puis _init sont exécutées successivement. Si nous ré-exécutons notre widget sur un élément du DOM déjà instancié, seul _init est appelée.
destroy() : Supprime l'instance du widget qui a été stocké en data dans notre élément du DOM. Le retour de l'élément du DOM, sur lequel est basé notre widget, dans l'état où il était avant la création du widget est à notre charge.
option(String key[, String value]) ou option(JSON {key1 : value1, key2 : value2} ) : Renvoi ou modifie une ou plusieurs options de notre widget.
enable() : Met l'option disabled à false. Le widget est libre de respecter ou non cette option.
disable() : Met l'option disabled à true. Le widget est libre de respecter ou non cette option.

Rien ne vous oblige à implémenter toutes ces méthodes. Si vous le faites ce sont des possibilités supplémentaires que vous offrez aux utilisateurs de votre plugin. Nous imaginons rarement tout ce que les utilisateurs peuvent vouloir faire avec nos créations. Vous ne voyez peut-être pas l'utilité de pouvoir réinitialiser, détruire ou désactiver votre widget mais il y a de fortes chances pour que certains de vos utilisateurs en aient besoin.

Voyons maintenant tout cela dans le détail en essayant de trouver des applications fonctionnelles sur notre exemple fil rouge. Je vous laisse juge du résultat dans la démo en fin d'article.

_init

Je m'auto-cite : « À la création d'un widget _create puis _init sont exécutées successivement. Si nous ré-exécutons notre widget sur un élément du DOM déjà instancié, seul _init est appelée. »

Si nous poussons le résonnement, _create doit contenir la création d'éléments indispensables à notre widget mais indépendants de toutes options. A l'inverse _init doit juste se contenter de modifications sur le widget en fonction des options.

Dans le cadre de notre exemple cela veut donc dire que l'encapsulation de notre élément dans un container et que la création du bloc pour le titre doivent être dans _create. Par contre la modification du contenu du titre et l'application du toggle, qui eux dépendent d'options, doivent se faire dans l'_init.

Reprenons notre code.

// La fonction _create est appel�e � la construction du widget
_create: function() {
    this.uiBlocContainer = $('<div></div>')
        .addClass('ui-bloc ui-widget ui-widget-content ui-corner-all')
        .insertAfter(this.element);

    this.element.addClass('ui-bloc-content').appendTo(this.uiBlocContainer);

    this.uiBlocTitle = $('<h5></h5>').addClass('ui-bloc-title ui-widget-header ui-corner-top')
        .prependTo(this.uiBlocContainer);

    // On encapsule un SPAN dans le bloc titre pour y �crire le titre et pouvoir le modifier � posteriori
    $('<span></span>').appendTo(this.uiBlocTitle);

    // On ajoute un SPAN au bloc titre pour le picto indicateur de l'�tat d'ouverture / fermeture
    // Mais on le cache au cas o� la fonctionnalit� serait d�sactiv�e
    this.uiBlocTitleToggle = $('<span></span>')
        .addClass('ui-bloc-title-toggle ui-icon ui-icon-pin-s')
        .appendTo(this.uiBlocTitle)
        .hide();
},

// La fonction _init est appel�e � la construction ET � la r�initialisation du widget
_init : function() {
    var self = this;

    // On renseigne le texte du titre avec la valeur pr�sente dans les options
    self.uiBlocTitle.children('span:first').text(self.options.title);

    // On enl�ve l'�v�nement click sur le bloc titre
    // En cas de r�initialisation, cela �vite d'ajouter un nouvel �v�nement click
    // � notre titre qui en a d�j� potentiellement un
    self.uiBlocTitle.unbind('click');

    if (self.options.togglable) {
        // On ajoute l'�v�nement click au bloc titre si le bloc est ouvrable / fermable
        self.uiBlocTitle.click(function(event) {
            self.toggle(event);
            return false;
        }).css('cursor', 'pointer'); // On modifie le curseur au survol du titre

        // On affiche le picto indicateur de l'�tat d'ouverture / fermeture
        // pr�c�demment cr�e dans _create
        self.uiBlocTitleToggle.show();

        if (!self.options.opened) {
            // Si le bloc est initialis� avec le param�tre opened � false, on ferme le bloc
            self._close();
        } else {
            // Si le bloc est initialis� avec le param�tre opened � true, on ouvre le bloc
            self._open();
        }
    } else {
        // Le bloc n'est pas togglable
        // On r�initialise le curseur au survol du titre
        self.uiBlocTitle.css('cursor', 'auto');
        // On cache le picto indicateur de l'�tat d'ouverture / fermeture
        self.uiBlocTitleToggle.hide();
        // On ouvre le bloc
        self._open();
    }
},

toggle : function() {
    var self = this;

    if (!self.options.togglable) {
        return self;
    }

    if (self.options.opened) {
        if (false === this._trigger('beforeClose')) {
            return false;
        }

        self._close();

        this._trigger('close');
    } else {
        if (false === this._trigger('beforeOpen')) {
            return false;
        }

        self._open();

        this._trigger('open');
    }
    self.options.opened = !self.options.opened;

    return self;
},

_close: function() {
    this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');
},

_open: function() {
    this.uiBlocContainer.children().show();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-w').addClass('ui-icon-pin-s');
}

A noter que la méthode _title − elle encapsulait la création et l'initialisation du bloc titre − a été purement et simplement détruite.

destroy

Maintenant que l'on a bien séparé ce qui était de la création et de l'initialisation, la méthode destroy revient à défaire ce que fait _create.

Allons-y gaiement.

// La fonction destroy ram�ne l'�l�ment du DOM, sur lequel est bas� notre widget,
// dans l'�tat o� il �tait avant la cr�ation du widget.
// Elle d�fait ce que _create a fait
destroy: function() {
    // On r�affiche l'�l�ment �ventuellement cach�
    // On enl�ve les classes css propres au widget
    // Et on sort l'�l�ment du container
    this.element.show()
        .removeClass('ui-bloc-content')
        .insertBefore(this.uiBlocContainer);

    // On d�truit le container
    // Ce qui d�truit par ricochet tous les autres �l�ments cr��s par notre widget
    this.uiBlocContainer.remove();

    // On appelle la m�thode originale du framework
    // Elle supprime l'instance du widget qui a �t� stock� en data dans l'�l�ment
    $.Widget.prototype.destroy.apply(this);

    return this;
},

option

Cette méthode sert aussi bien de setter que de getter. Elle peut traiter une seule option ou plusieurs en même temps.

option() : renvoie le JSON des options de notre widget
option(String key) : renvoie la valeur de l'option key
option(String key, value) : met à jour l'option key avec la valeur value dans le JSON d'options de notre widget
option(JSON {key1 : value1, key2 : value2}) : fusionne le JSON passé en paramètre avec le JSON d'options de notre widget

En mode setter, l'implémentation par défaut de la méthode option dans le framework jQuery UI se contente de modifier la ou les options. Si ces modifications impliquent une mise à jour de votre widget, c'est à vous de surcharger option pour répercuter ces modifications − en n'oubliant pas d'appeler la méthode originale. En fait, la méthode option du framework appelle 2 autres méthodes : _setOptions quand le paramètre est un JSON et _setOption quand le premier paramètre est une chaîne. _setOptions appelle elle-même _setOption pour chaque clé du JSON. Ce n'est donc pas option qu'il faut surcharger mais _setOption.

// Surcharge de la m�thode _setOption qui est appel�e par la m�thode option
// qui permet de modifier des options de notre widget
_setOption: function(key, value){
    var self = this;

    // On appelle la m�thode originale du framework qui modifie le tableau d'options
    $.Widget.prototype._setOption.apply(self, arguments);

    if ($.inArray(key, ['title', 'togglable', 'opened']) != -1) {
        // Si l'option modifi�e est une des 3 options title, togglable, opened
        // On appelle la m�thode d'initialisation
        self._init();
    }
},

Notre ancienne méthode title − elle agissait comme un setter / getter sur l'option title − ne sert plus à rien : Poubelle !

enable / disable

Par défaut dans le framework jQuery UI, ces deux méthodes font deux choses :

Elles modifient l'option disabled respectivement à false et à true
Elles suppriment / ajoutent une classe css ui-state-disabled sur notre élément

Si notre élément de base du widget servait lui-même de container aux éléments créés par le widget, l'aspect visuel du widget pourrait simplement être changé via la classe ui-state-disabled.

Mais avant d'aller plus loin il nous faut définir ce que signifie "désactivé notre widget". Si notre widget était juste un bouton, ça pourrait être un simple grisage et la désactivation du clic. Dans notre cas je propose :

Grisage du bloc (titre et contenu)
Désactivation du clic sur le titre dans le cas où le bloc serait togglable

Plutôt que de redéfinir enable et disable, nous allons utiliser l'option disabled gérée nativement. On va donc revenir dans _setOption pour le grisage.

_setOption: function(key, value){
    var self = this;

    $.Widget.prototype._setOption.apply(self, arguments);

    if ($.inArray(key, ['title', 'togglable', 'opened']) != -1) {
        self._init();
    } else if (key === 'disabled') {
        // L'option disabled a �t� modifi�e
        // On ajoute ou supprime, en fonction du cas, la classe ui-state-disabled au container
        // Dans le framework css de jQuery UI, la classe ui-state-disabled grise un �l�ment
        if (value) {
            this.uiBlocContainer.addClass('ui-state-disabled');
        } else {
            this.uiBlocContainer.removeClass('ui-state-disabled');
        }
    }
},

Pour la désactivation du clic sur le titre on va se contenter de modifier l'événement click définit dans _init.

self.uiBlocTitle.click(function(event) {
    // Si le widget est disabled, il ne se passe rien au click
    if (!self.options.disabled) {
        self.toggle(event);
        return false;
    }
});

La démo !

Comme promis la démo de toutes ces nouvelles fonctionnalités.

La suite : héritage

Sixième chapitre : héritage

D�velopper un plugin jQuery UI : �v�nements

Gilles Felix — Thu, 11 Aug 2011 16:54:00 +0200

Voici le quatri�me chapitre de notre tutoriel. Aujourd'hui, int�ressons-nous aux �v�nements.

Sommaire du tutoriel
Développer un plugin jQuery UI

Notre bloc a pris forme. Il est maintenant ouvrable et fermable.

Imaginons qu'un autre développeur utilise le plugin et qu'il veuille déclencher une action à chaque fois que le bloc s'ouvre ou se ferme. En l'état, il serait obligé de modifier directement le code source du plugin (dans les méthodes _close et _open) pour y implanter ses actions. Une option pas franchement intelligente : à la prochaine mise à jour du plugin, il faudra qu'il refasse la même manipulation.

Facilitons la vie de ce pauvre développeur. Deux choix s'offrent à nous.

Ajoutons des callbacks

Les callbacks sont des fonctions javascript passées en paramètre, destinées à être exécutées lors d'un événement précis.

Ajoutons donc deux options à notre widget.

options: {
    title: 'Titre',
    togglable: true,
    opened : true, 
    open : null, // Variable de type callback � d�clencher � l'ouverture
    close : null // Variable de type callback � d�clencher � la fermeture
},

Modifions nos méthodes _open et _close pour tenir compte de ces options.

_close: function() {
    this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');

    // On v�rifie si l'option close est bien une fonction
    if ($.isFunction(this.options.close)) {
        // Ex�cution de la fonction close avec comme contexte l'instance de notre widget (this)
        this.options.close.call(this); 
    }
},

_open: function() {
    this.uiBlocContainer.children().show();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-w').addClass('ui-icon-pin-s');

    // On v�rifie si l'option open est bien une fonction
    if ($.isFunction(this.options.open)) {
        // Ex�cution de la fonction open avec comme contexte l'instance de notre widget (this)
        this.options.open.call(this); 
    }
},

Et pour finir, modifions l'initialisation de notre bloc.

$('#monbloc1').bloc({
    title: 'Hello bloc 1',
    open: function() {
        // this repr�sente l'instance de notre widget
        alert('Ouverture > ' + this.options.title);
    },
    close: function() {
        alert('Fermeture > ' + this.options.title);
    }
});

Je ne vous fais pas de démo mais ayez confiance, ça marche parfaitement.

Vous l'avez peut-être compris, la deuxième solution à ma préférence.

Ajoutons des triggers

Cette solution est légèrement différente. Plutôt que de déclencher les actions de l'intérieur du plugin quand les événements surviennent, envoyons juste une information à l'élément de notre widget comme quoi l'événement a eu lieu. L'avantage est qu'on n'est pas obligé de définir l'action à l'initialisation du widget. On peut le faire a posteriori aussi simplement que l'on intercepte un événement click sur un bouton (ce n'est pas tout à fait vrai, c'est également possible avec la première solution en utilisant le setter $('#monbloc').('open', function() {...}); mais c'est un peu plus compliqué et moins intuitif).

Pour envoyer le signal de l'événement, il existe la méthode trigger avec jQuery. Le framework jQuery UI, dans sa grande bonté, fournit la méthode _trigger qui en fait un peu plus. Que fait-elle de plus ?

Elle ajoute le nom de votre widget en préfixe du nom de l'événement (si vous déclenchez un événement nommé close, l'événement réellement propagé sera nomduwidgetclose). Pas de conflit possible avec d'autres événements pouvant être déclenchés par d'autres plugins ou par le framework.
Elle crée automatiquement un objet $.Event si vous n'en fournissez pas un.
And last but not least, elle vérifie si une option de type callback du même nom que votre événement – sans le préfixe du widget – existe. Si c'est le cas, elle l'exécute avec, comme contexte, l'élément de votre widget.

Mise en application, toujours dans nos deux méthodes _open et _close.

_close: function() {
    this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');

    // Envoi du signal de fermeture
    // _trigger accepte 3 param�tres, les deux derniers �tant optionnels : 
    // - le nom de l'�v�nement
    // - l'objet �v�nement
    // - des donn�es additionnelles envoy�es aux fonctions interceptant l'�v�nement
    this._trigger('close');
},

_open: function() {
    this.uiBlocContainer.children().show();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-w').addClass('ui-icon-pin-s');

    // Envoi du signal d'ouverture
    this._trigger('open');
},

Le code d'initialisation de notre bloc fourni dans la première solution basée sur les callbacks fonctionne toujours. Mais, maintenant, on peut aussi faire ça :

$('#monbloc1').bloc({
    title: 'Hello bloc 1',
});
$('#monbloc1').bind('blocopen', function() {
    // this repr�sente l'�l�ment sur lequel est appliqu� notre widget bloc
    alert('Ouverture > ' + $(this).text());
});
$('#monbloc1').bind('blocclose', function() {
    alert('Fermeture > ' +  $(this).text());
});

Osons l'interruptionnabilité !!

Je sens qu'il vous reste encore quelques neurones pour une dernière étape dans ce chapitre. L'utilisateur de notre plugin peut maintenant être averti de l'ouverture et de la fermeture du bloc. Bien ! Mais, ce qu'il veut, lui, c'est pouvoir arrêter l'ouverture et la fermeture s'il le décide.

_close: function() {
    // Si l'�v�nement beforeClose retourne false, on arr�te la fermeture
    if (false === this._trigger('beforeClose')) {
        return;
    }

    this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');

    this._trigger('close');
},

_open: function() {
    // Si l'�v�nement beforeOpen retourne false, on arr�te l'ouverture
    if (false === this._trigger('beforeOpen')) {
        return;
    }

    this.uiBlocContainer.children().show();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-w').addClass('ui-icon-pin-s');

    this._trigger('open');
},

MAJ du 17/08/2011

Petit bug dans l'ajout des événements beforeClose et beforeOpen : si les événements renvoient false, les méthodes − respectivement _close ou _open − doivent renvoyer false aussi et non pas simplement return;. De cette façon, la méthode toggle peut, elle aussi, tester le retour de _open et _close et s'arrêter s'il le faut.

toggle : function() {
    var self = this;

    if (!self.options.togglable) {
        return self;
    }

    if (self.options.opened) {
        // Si _close renvoie false, arr�t de l'ex�cution de toggle 
        if (!self._close()) {
            return;
        }
    } else {
        // Si _open renvoie false, arr�t de l'ex�cution de toggle 
        if (!self._open()) {
            return;
        }
    }
    self.options.opened = !self.options.opened;

    return self;
},

MAJ du 24/08/2011

Le patch du 17 août corrigeait un bug mais il en a introduit un autre. Les méthodes _open et _close ne faisaient aucun return final, toggle interprétait ça comme un false et s'arrêtait. Résultat : le premier toggle marchait mais les suivants non. Je ne vous fais pas l'affichage du bout de code : ajouter simplement return true; à la fin des méthodes _open et _close.

Corrigeons un effet de bord

Je ne vous cache rien. En l'état, ce plugin a un petit bug. La méthode _close est appelée lors de la fermeture du bloc, mais également à l'initialisation si l'utilisateur a demandé à ce que le bloc soit fermé par défaut. S'il a, en plus, ajouté des options close ou beforeClose pour exécuter des callbacks aux déclenchements de ces événements, ces callbacks s'exécuteraient aussi à la création du bloc. C'est tout de même un peu ballot. Corrigeons rapidement ça.

_create: function() {
    this.uiBlocContainer = $('<div></div>')
        .addClass('ui-bloc ui-widget ui-widget-content ui-corner-all')
        .insertAfter(this.element);

    this.element.addClass('ui-bloc-content').appendTo(this.uiBlocContainer);
    this._title();

    if (this.options.togglable && !this.options.opened) {
        // Le param�tre true est l� pour indiquer � la m�thode _close qu'elle est appel�e par la cr�ation du widget
        this._close(true);
    }
},

_close: function(isCreate) {
    // Pas d'�v�nement si c'est la cr�ation du widget
    if (!isCreate && false === this._trigger('beforeClose')) {
        return;
    }

    this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');

    if (!isCreate) {
        this._trigger('close');
    }
},

La démo, la démo !!!

Juste une précision avant la démo. Quand vous interceptez vos événements, le nom de l'événement est en minuscule. Dans notre cas, il faut donc intercepter blocbeforeopen et non blocbeforeOpen.

La suite : fonctionnalités avancées

Passons à la cinquième étape, les fonctionnalités avancées

D�velopper un plugin jQuery UI : options et m�thodes

Gilles Felix — Thu, 04 Aug 2011 10:34:00 +0200

Apr�s une pause vacances, reprenons notre tutoriel sur comment d�velopper un plugin jQuery UI. Aujourd'hui, allons un peu plus loin dans les options et les m�thodes.

Sommaire du tutoriel
Développer un plugin jQuery UI

Faisons maintenant évoluer notre exemple fil rouge. Pour l'instant, on transforme un DIV en un bloc avec titre, dont le look dépend du thème jQuery UI choisi. Le but de l'étape du jour va être de pouvoir ouvrir et fermer notre bloc en cliquant sur son titre.

Ajoutons une méthode toggle

Commençons par écrire une méthode toggle qui aura comme but de cacher le contenu du bloc quand il est visible et lycée de Versailles.

Ajoutons une variable opened à nos options.

    options: {
        title: 'Titre',
        opened : true // Variable indiquant si le bloc est ouvert 
    },

Et voici maintenant notre méthode toggle (et ses sous-méthodes _open et _close).

    toggle : function() {
        var self = this;
        if (self.options.opened) {
            self._close();
        } else {
            self._open();
        }
        // On inverse la valeur de l'option opened
        self.options.opened = !self.options.opened;

        // On retourne l'instance du plugin pour pr�server le cha�nage des fonctions
        return self;
    }

    _close: function() {
        // On doit cacher tous les enfants du container sauf le titre
        this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
    },

    _open: function() {
        // On doit afficher tous les enfants du container
        this.uiBlocContainer.children().show();
    },

Modifions également notre méthode _create pour tenir compte du paramètre opened.

    _create: function() {
        this.uiBlocContainer = $('<div></div>')
            .addClass('ui-bloc ui-widget ui-widget-content ui-corner-all')
            .insertAfter(this.element);

        this.element.addClass('ui-bloc-content').appendTo(this.uiBlocContainer);
        this._title();

        if (!this.options.opened) {
            // Si le bloc est initialis� avec le param�tre opened � false, on ferme le bloc
            this._close();
        }
    },

En l'état, notre plugin permet déjà d'ouvrir et fermer le bloc via un appel extérieur (la fonction toggle ne commençant pas par un underscore) et d'afficher un bloc fermé par défaut.

<div>
  <button id="action1">Changer le titre</button>
  <button id="action2">Alert : le titre</button>
  <button id="action3">Toggle</button>
</div>
<script type="text/javascript">
(function($) {
    $(function() {
        $('#monbloc').bloc({
            title : 'Hello world',
            opened : false // Ce bloc est ferm� par d�faut
        });

        // Le clic sur le bouton Toggle ouvre et ferme alternativement le bloc
        $('#action3').click(function() {
            // On rappelle la fonction bloc sur l'�l�ment
            // avec en param�tre le nom de la fonction interne (toggle)
            $('#monbloc').bloc('toggle');
        }) ;
    });
})(jQuery);
</script>

Appellons toggle quand le titre est cliqué

Faisons maintenant en sorte qu'un clic sur la barre de titre déclenche ce fameux toggle. Pour cela, modifions notre méthode interne de génération du titre : _title.

    _title: function() {
        var self = this;

        this.uiBlocTitle = $('<h5></h5>').addClass('ui-bloc-title ui-widget-header ui-corner-top')
            .text(this.options.title)
            // On ajoute l'�v�nement clic � notre titre
            .click(function(event) {
                self.toggle(event);
                return false;
            })
            .prependTo(this.uiBlocContainer);
    },

Pensons à l'utilisateur

Ce n'est déjà pas mal, mais, si on se place dans la peau de l'utilisateur, rien ne nous indique que le titre est cliquable. On va donc modifier le curseur au survol du titre et ajouter aussi une icône à droite de la barre de titre indiquant l'état d'ouverture / fermeture du bloc.

    _title: function() {
        var self = this;

        self.uiBlocTitle = $('<h5></h5>').addClass('ui-bloc-title ui-widget-header ui-corner-top')
            .text(self.options.title)
            .click(function(event) {
                self.toggle(event);
                return false;
            })
            .css('cursor', 'pointer') // On modifie le curseur au survol du titre
            .prependTo(this.uiBlocContainer);

        // On ajoute un SPAN � notre titre
        // la classe ui-bloc-title-toggle va nous servir � placer le SPAN � droite dans la barre de titre
        // la classe ui-icon associ�e � la classe ui-icon-pin-s
        // va transformer notre SPAN en une ic�ne de t�te d'�pingle orient�e sud (vers le bas)
        self.uiBlocTitleToggle = $('<span></span>')
            .addClass('ui-bloc-title-toggle ui-icon ui-icon-pin-s')
            .appendTo(self.uiBlocTitle);
    },

Ajoutons la classe ui-bloc-title-toggle à notre CSS.

.ui-bloc .ui-bloc-title {
    /* Le titre est en position relative pour permettre au picto toggle (classe ui-bloc-title-toggle)
    d'�tre positionn� en absolu par rapport � lui */
    position: relative;
    margin: 0 0 10px;
    padding: 5px;
}
.ui-bloc .ui-bloc-title-toggle {
    position: absolute;
    right: 0.3em;
    top: 50%;
    width: 16px;
    margin: -8px 0 0 0;
    padding: 1px;
    height: 16px;
    display:block;
}

Et pour être au top, modifions l'icône en fonction de l'état d'ouverture / fermeture.

    _close: function() {
        this.uiBlocContainer.children().not(this.uiBlocTitle).hide();
        // L'ic�ne de la barre de titre devient une t�te d'�pingle orient�e vers l'ouest (west, donc vers la gauche)
        this.uiBlocTitleToggle.removeClass('ui-icon-pin-s').addClass('ui-icon-pin-w');
    },

    _open: function() {
        this.uiBlocContainer.children().show();
        // L'ic�ne de la barre de titre devient une t�te d'�pingle orient�e vers le sud (vers le bas)
        this.uiBlocTitleToggle.removeClass('ui-icon-pin-w').addClass('ui-icon-pin-s');
    },

Rendons la fonctionnalité toggle optionnelle

Pour finir ce chapitre du tutoriel, nous allons rendre la fonctionnalité toggle optionnelle. Pour cela, ajoutons une nouvelle variable à nos options.

    options: {
        title: 'Titre',
        togglable: true, // Variable indiquant si le bloc est ouvrable / fermable
        opened : true
    },

Il faut maintenant conditionner tout le code portant sur la fonctionnalité.

    _title: function() {
        var self = this;

        self.uiBlocTitle = $('<h5></h5>').addClass('ui-bloc-title ui-widget-header ui-corner-top')
            .css('cursor', 'pointer') 
            .prependTo(this.uiBlocContainer);

        $('<span></span>').text(self.options.title)
            .appendTo(self.uiBlocTitle);

        if (self.options.togglable) {
            // On ajoute l'�v�nement clic � notre titre si le bloc est ouvrable / fermable
            self.uiBlocTitle.click(function(event) {
                self.toggle(event);
                return false;
            })

            self.uiBlocTitleToggle = $('<span></span>')
                .addClass('ui-bloc-title-toggle ui-icon ui-icon-pin-s')
                .appendTo(self.uiBlocTitle);
        }
    },

    toggle : function() {
        var self = this;

        //Si le bloc n'est pas ouvrable / fermable, on sort tout de suite
        if (!self.options.togglable) {
            return self;
        }

        if (self.options.opened) {
            self._close();
        } else {
            self._open();
        }
        self.options.opened = !self.options.opened;

        return self;
    }

La démo de notre plugin en l'état

La démo porte maintenant sur deux blocs, un togglable, l'autre non .

La suite : les événements

Passons à la quatrième étape, les événements

D�velopper un plugin jQuery UI : mise en forme

Gilles Felix — Tue, 12 Jul 2011 14:39:00 +0200

Dans la premi�re partie, nous avons vu comment cr�er un plugin jQuery UI � partir d'un exemple basique. Poursuivons et mettons en forme notre exemple.

Sommaire du tutoriel
Développer un plugin jQuery UI

Le framework CSS jQuery UI

Le framework CSS jQuery UI fournit une librairie de classes de base à appliquer à nos éléments. Il faut bien sûr ensuite ajouter ses propres classes pour affiner le look.

Voici la page du projet jQuery UI décrivant les classes CSS de base. En complément, il faut garder sous le coude la page du ThemeRoller, qui va nous fournir les classes associées à chaque icone du thème.

Retour à l'exemple

Commençons par ajouter la feuille CSS du thème jQuery UI (dans notre cas, c'est le thème de base ui-lightness) et quelques CSS spécifiques.


<link rel="stylesheet" type="text/css" href="static/js/jquery-ui/css/ui-lightness/jquery-ui-1.8.14.custom.css">
<style type="text/css">
.ui-bloc {
 padding : 0;
 margin-bottom: 10px;
}
.ui-bloc-content {
 margin : 10px;
}
.ui-bloc-title {
 margin : 0 0 10px;
 padding : 5px;
}
</style>

Revenons à notre méthode _create de création du widget

_create: function() {
    // On cr�e un container pour notre nouvel �l�ment d'UI
    // On lui ajoute la classe ui-widget qui doit �tre ajout�e � tout container de widget
    // On lui ajoute �galement la classe ui-widget-content qui doit �tre appliqu�e  � tout container de contenu de widget
    // La classe ui-corner-all arrondit les 4 angles de notre bloc
    this.uiBlocContainer = $('<div></div>').addClass('ui-bloc ui-widget ui-widget-content ui-corner-all').insertAfter(this.element);

    // On encapsule notre �l�ment initial dans notre nouveau container
    this.element.addClass('ui-bloc-content').appendTo(this.uiBlocContainer);
    this._title() ;
},

Dans notre méthode _title, améliorons le look du titre.

_title: function() {
    // On ajoute la classe ui-widget-header qui doit �tre ajout�e � tout �l�ment titre de widget
    // La classe ui-corner-top arrondit les 2 angles supp�rieurs de notre bloc titre
    // L'�l�ment uiBlocTitle est ajout� au container et non plus � notre �l�ment de base
    this.uiBlocTitle = $('<h5></h5>').addClass('ui-bloc-title ui-widget-header ui-corner-top').text(this.options.title).prependTo(this.uiBlocContainer);
},

Observons le résultat

La suite : options et méthodes

Passons à la troisième étape, options et méthodes

D�velopper un plugin jQuery UI : introduction

Gilles Felix — Mon, 11 Jul 2011 12:24:00 +0200

Tout utilisateur de jQuery conna�t la librairie jQuery UI fournie par l'�quipe officielle de jQuery.

jQuery UI fourni des effets suppl�mentaires, des plugins basses couches d'interactions et des widgets packag�s pr�ts � l'emploi. Tous les plugins jQuery UI sont construits de la m�me fa�on et bas�s sur un syst�me de th�mes CSS compl�tement personnalisables. Il y a m�me � disposition une application de ThemeRoller pour construire son propre th�me et un widget Theme Switcher pour pouvoir modifier son th�me � la vol�e.

Sommaire du tutoriel
Développer un plugin jQuery UI

J'utilise régulièrement quelques-uns des widgets officiels et j'ai utilisé les plugins d'interactions pour développer quelques plugins spécifiques. Mais, je ne m'étais jamais attardé sur l'API sous-jacente à jQuery UI. C'est un tort.

Dans le cadre d'un des projets de Novius Labs, j'avais besoin d'un ensemble d'UI. J'ai commencé par faire un inventaire de tous les plugins jQuery existants qui pouvait me servir. Mais, au final, j'avais une liste de plugins sans cohérence et j'aurais été obligé pour chacun de mettre les mains dans le cambouis, pour leur faire faire ce que je voulais.

Parmi cette liste de plugins, il y avait plusieurs widgets jQuery UI. J'ai donc creusé un peu de ce côté là. Je pris le temps de lire la page jQuery UI API Developer Guide, qui m'a renvoyé vers ce tutorial Understanding jQuery UI widgets: A tutorial. J'ai alors découvert le framework qui me manquait pour développer mes plugins.

Jusqu'à présent, à chaque fois que je devais coder un plugin, je repartais « from scratch ». Avec le framework jQuery UI, toute la logique est déjà pré-pensée, que ce soit pour le JavaScript que pour le CSS. Plus fort, je peux utiliser facilement le système d'héritage pour modifier un plugin existant.

Passons à la pratique. Notre exemple est basique : transformation d'un DIV en un bloc avec titre.

Le code de base d'un widget jQuery UI

// Pour cr�er mon plugin il suffit d'appeller la m�thode $.widget
// Le 1er param�tre est le nom de mon plugin pr�fix� par demo. (le namespace du widget, ui �tant le namespace de jQuery UI)
// Le 2eme param�tres est un objet json de param�trage du plugin
$.widget("demo.bloc", {
    // options par d�faut du widget 
    // modifiables � la construction 
    // mais aussi apr�s la construction du widget 
    options: {
        title: 'Titre'
    },

    // Une variable interne 
    // contient l'objet jQuery du titre du bloc
     uiBlocTitle: null,

    // La fonction _create est appel� � la construction du widget
    // la variable d'instance this.element contient un objet jQuery
    // contenant l'�l�ment sur lequel porte le widget
    _create: function() {
        this.element.addClass('uiBloc');
        this._title() ;
    },

    // Toutes les fonctions commen�ant par un underscore
    // sont des fonctions internes
     _title: function() {
        this.uiBlocTitle = $('<h5></h5>').text(this.options.title).prependTo(this.element);
     },

    // Les fonctions ne commen�ant pas par un underscore
    // sont des fonctions pouvant �tre appel�es de l'ext�rieur
    title: function(text) {
        if (typeof(text)!= 'undefined') {
            // la variable text a �t� pass�e en param�tre
            // Modification du texte
            // et ne pas oublier de retourner l'�l�ment (this.element)
            // pour rendre possible le chainage de fonction
            returnthis.uiBlocTitle.text(text);
        } else {
            // la variable text n'a pas �t� pass�e en param�tre
            // On retourne le texte actuellement contenu dans l'�l�ment
            returnthis.uiBlocTitle.text();
        }
    }
});

Voici maintenant le code d'utilisation

<div id="monbloc">
 <p>Far far away, behind the word mountains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of the Semantics, a large language ocean. A small river named Duden flows by their place and supplies it with the necessary regelialia. It is a paradisematic country, in which roasted parts of sentences fly into your mouth. Even the all-powerful Pointing has no control about the blind texts it is an almost unorthographic life One day however a small line of blind text by the name of Lorem Ipsum decided to leave for the far World of Grammar. The Big Oxmox advised her not to do so, because there were thousands of bad Commas, wild Question Marks and devious Semikoli, but the Little Blind Text didn?t listen. She packed her seven versalia, put her initial into the belt and made herself on the way. When she reached the first hills of the Italic Mountains, she had a last view back on the skyline of her hometown Bookmarksgrove, the headline of Alphabet Village and the subline of her own road, the Line Lane. Pityful a rethoric question ran over her cheek, then </p>
</div>
<div>
 <button id="action1">Changer le titre</button>
 <button id="action2">Alert : le titre</button>
</div>
<script type="text/javascript" src="static/js/jquery-ui/js/jquery-ui-1.8.14.custom.min.js"></script>
<script type="text/javascript">
(function($) {
     $(function() {
         // Appel de la construction du widget
         // en surchargeant les options par d�faut
         $('#monbloc').bloc({title : 'Hello world'});

        // Un click sur le bouton Change modifie le texte
        // On rappelle la fonction bloc sur l'�l�ment
        // Le premier param�tre est le nom de la fonction interne (title)
        // Le deuxi�me est le param�tre de la fonction interne
        $('#action1').click(function() {
            $('#monbloc').bloc('title', 'Bonjour monde');
        }) ;

         // Un click sur le bouton Alert affiche le texte en cours dans une alert
         $('#action2').click(function() {
             alert($('#monbloc').bloc('title'));
         }) ;
     });
})(jQuery);
</script>

Et maintenant la démo

La suite : le skinnage

Passons à la deuxième étape, la mise en forme de notre UI