dimanche 4 mai 2008
Par NiKo le dimanche 4 mai 2008, 16:38 - Dev
Une belle quote comme ça, je me la note dans un coin pour la ressortir la prochaine fois qu'on trolle sur les performances du framework X ou du langage Y :
Languages, libraries and frameworks don't scale. Architectures do.
En français approchant :
Les langages de programmation, les librairies et les frameworks ne tiennent pas la charge. Les architectures, si.
(via, apparement attribuable à Cal Henderson)
jeudi 13 mars 2008
Par NiKo le jeudi 13 mars 2008, 11:52 - Dev
Dans la liste des tâches nouvellement ajoutées en Symfony 1.1, on remarque une section dédiée à l'internationalisation :
i18n :extract Extracts i18n strings from php files :find Finds non "i18n ready" strings in an application
Et oui, la fonctionnalité dont tous les gens qui ont un jour travaillé sur des applications internationalisées en Symfony 1.0 ont rêvé a enfin été ajoutée : une tâche d'extraction des chaînes de caractères à traduire, avec génération et mise à jour des fichiers de traductions XLIFF 
Si vous avez suivi les précédents tutoriels, vous devez disposer d'un projet sf11test, d'une application main et d'un module contact.
On va activer la gestion de l'internationalisation dans l'application en éditant le fichier de configuration apps/main/config/settings.yml comme suit :
[...]
all:
[...]
.settings:
[...]
i18n: on
[...]
standard_helpers: [Partial, Cache, Form, I18N]
[...]
default_culture: en
On part du principe que la langue par défaut sera l'anglais (en). Ajoutons quelques chaînes internationalisées dans le template apps/main/modules/contact/templates/indexSuccess.php au moyen du helper __() :
<h2><?php echo __('Contact us') ?></h2> <p><?php echo __('Drop us a message using the form below:') ?></p> <form action="<?php echo url_for('contact/index') ?>" method="post"> <table> <?php echo $form ?> <tr> <td></td> <td><input type="submit" value="<?php echo __('Send your message') ?>" /></td> </tr> </table> </form>
Maintenant, lançons la commande d'extraction des chaînes à traduire pour notre future version française, en lui demandant poliment de générer automatiquement le fichier de traduction et de supprimer automatiquement les entrées orphelines :
$ ./symfony i18n:extract --auto-save --auto-delete main fr >> i18n extracting i18n strings for the "main" application >> i18n found "3" new i18n strings >> i18n found "0" old i18n strings >> i18n saving new i18n strings >> i18n deleting old i18n strings
Le fichier apps/main/i18n/fr/messages.xml a été généré, examinons son contenu :
<?xml version="1.0"?> <xliff version="1.0"> <file source-language="EN" target-language="fr" datatype="plaintext" original="messages" date="2008-03-13T11:13:45Z" product-name="messages"> <body> <trans-unit id="1"> <source>Contact us</source> <target></target> </trans-unit> <trans-unit id="2"> <source>Drop us a message using the form below:</source> <target></target> </trans-unit> <trans-unit id="3"> <source>Send your message</source> <target></target> </trans-unit> </body> </file> </xliff>
Il ne nous reste plus qu'à traduire nos chaînes en remplissant les balises <target></target> en conséquence pour traduire notre application en français. Si l'on venait à modifier notre template en supprimant, modifiant ou ajoutant de nouvelles chaînes, la tâche d'extraction se chargerait de mettre à jour nos fichiers de traduction en conséquence, tout en préservant le travail déjà effectué
mardi 11 mars 2008
Par NiKo le mardi 11 mars 2008, 10:50 - Dev
Nous venons de voir la procédure d'installation de la beta1 de Symfony 1.1. Nous allons maintenant rentrer un peu plus dans les détails des nouvelles fonctionnalités en commençant par les formulaires.
La nouvelle gestion des formulaires est l'une des fonctionnalités majeures de cette nouvelle mouture du framework. Elle propose une séparation claire entre couche de contrôle, couche de définition et couche de présentation des données, soit un bon vieux pattern MVC des familles.
Pour illustrer ces fonctionnalités, nous allons retrousser nos manches et créer un formulaire de contact basique. On commence par initialiser un nouveau module contact dans l'application main de notre projet sf11test initié précédemment :
$ ./symfony generate:module main contact
Nous allons créer une classe qui représentera notre formulaire de contact, que nous stockerons dans le fichier apps/main/lib/ContactForm.class.php. Cette classe étendra la classe de base sfForm et surchargera sa méthode de configuration afin de définir les champs de formulaire et les différents validateurs associés. Nous définirons quatre champs (appelés widgets en Symfony 1.1) :
<input type="text"/>)<select/>)<textarea/>)<?php class ContactForm extends sfForm { public function configure() { // Widgets $topics = sfConfig::get('app_contact_topics', array()); $widgetSchema = new sfWidgetFormSchema(array( 'topic' => new sfWidgetFormSelect(array('choices' => $topics)), 'name' => new sfWidgetFormInput(), 'email' => new sfWidgetFormInput(), 'message' => new sfWidgetFormTextarea() )); $widgetSchema->setNameFormat('contact[%s]'); // HTML field names format $this->setWidgetSchema($widgetSchema); // Validators $this->setValidators(array( 'topic' => new sfValidatorRegex(array('pattern' => '/[a-z_]/')), 'name' => new sfValidatorString(array('min_length' => 2, 'max_length' => 45)), 'email' => new sfValidatorAnd(array(new sfValidatorEmail(), new sfValidatorString(array('max_length' => 100)))), 'message' => new sfValidatorString(array('min_length' => 10)), )); } }
Au passage, nous ajoutons les sujets possibles de message dans le fichier de configuration apps/main/config/app.yml :
all:
contact:
topics:
carrots_request: Do you have carrots?
eggs_request: Do you have eggs?
Marquons un arrêt pour examiner de plus près ce que nous venons d'écrire :
emailN'oublions pas de purger le cache de Symfony, car nous venons d'ajouter un nouvel objet php :
$ ./symfony cc
Éditons maintenant le fichier apps/main/modules/contact/actions/actions.class.php pour y définir l'action par défaut du module[1] :
<?php class contactActions extends sfActions { public function executeIndex(sfWebRequest $request) { $form = new ContactForm(); if ($request->isMethod('post')) // If HTTP method is POST { // Bind submitted values to the contact form instance $form->bind($request->getParameter('contact')); // Validate the form if ($form->isValid()) { // Retrieve submitted values $values = $form->getValues(); // ... Send your message here using submitted values // Then redirect user to the homepage with a one-shot message $this->getUser()->setFlash('notice', 'Message sent'); $this->redirect('@homepage'); } } // Publish form instance to the view $this->form = $form; } }
Ici, dans l'ordre :
Vous noterez que tous les sinon sont gérés automatiquement par le framework de façon transparente (mais ces comportements par défaut sont toujours surchargeables) :
Enfin, il nous reste à créer un template pour présenter le formulaire et éventuellement afficher un message à l'utilisateur, dans notre vue gérée au travers du fichier apps/main/modules/contact/templates/indexSuccess.php :
<?php if ($sf_user->hasFlash('notice')): ?> <p class="notice"><?php echo $sf_user->getFlash('notice') ?></p> <?php endif; ?> <form action="<?php echo url_for('contact/index') ?>" method="post"> <table> <?php echo $form ?> <tr> <td></td> <td><input type="submit" /></td> </tr> </table> </form>
Si on charge la page /main_dev.php/contact, on a le résultat suivant :
Au passage si vous regardez la source, une protection anti CSRF est automatiquement gérée de façon transparente.
Bien entendu, le mode de rendu par défaut utilise un tableau pour la mise en forme, mais il existe un autre décorateur plus sémantique à base de liste. Pour l'utiliser, modifions notre classe ContactForm :
<?php class ContactForm extends sfForm { public function configure() { // ... $this->widgetSchema->setFormFormatterName('list'); } }
Il conviendra bien entendu d'adapter le template pour enlever les balises tables. On peut aussi imaginer de créer notre propre décorateur HTML. Par exemple, créeons la classe sfWidgetFormSchemaFormatterDiv comme suit :
<?php class sfWidgetFormSchemaFormatterDiv extends sfWidgetFormSchemaFormatter { protected $rowFormat = "<div class=\"form-row\">\n %error%%label%\n %field%%help%\n%hidden_fields%</div>\n", $errorRowFormat = "<div class=\"form-errors\">\n%errors%</div>\n", $helpFormat = '<div class="form-help">%help%</div>', $decoratorFormat = "<div>\n %content%</div>"; }
Encore une fois, modifions notre classe ContactForm pour l'utiliser (après avoir purgé le cache symfony, comme il se doit) :
<?php class ContactForm extends sfForm { public function configure() { // ... $this->widgetSchema->setFormFormatterName('div'); } }
Vous me direz, un simple <?php echo $form ?> n'est pas très satisfaisant du point de vue de l'intégration HTML, qui nécessite bien souvent de prendre la main finement sur le code html généré. Le framework de formulaires de Symfony 1.1 apporte une solution en permettant de générer le rendu de chacun des widgets de façon indépendante
Imaginons par exemple que nous souhaitions gérer spécifiquement la présentation du champ name de notre formulaire ; notre template devient alors :
<?php if ($sf_user->hasFlash('notice')): ?> <p class="notice"><?php echo $sf_user->getFlash('notice') ?></p> <?php endif; ?> <form action="<?php echo url_for('contact/index') ?>" method="post"> <table> <?php echo $form['topic']->renderRow() ?> <tr> <th><?php echo $form['name']->renderLabel() ?></th> <td> <?php echo $form['name']->renderError() ?> <?php echo $form['name']->render(array('class' => 'toto')) ?> </td> </tr> <?php echo $form['email']->renderRow() ?> <?php echo $form['message']->renderRow() ?> <tr> <td></td> <td><input type="submit" /></td> </tr> </table> </form>
Vous noterez qu'on accède ici aux différents widgets du formulaire au moyen de clés de tableaux classiques ; c'est tout simplement car la classe sfForm implémente l'interface ArrayAccess de la SPL. C'est très pratique !
Ayant été à une lointaine époque un fervent adepte de PEAR::FormBuilder, brique permettant de générer des formulaires à partir d'instance d'objets de données ORM, j'étais curieux de voir comment cette fonctionnalité demandée par les développeurs depuis longtemps allait être implémentée dans Symfony 1.1 au travers de l'ORM Propel, bundlé par défaut[3].
Après avoir configuré un accès à notre SGBD préféré[4], nous allons définir une table contact_demand dans notre fichier config/schema.yml pour y stoker nos demandes de contacts :
propel:
contact_demand:
id:
name: { type: varchar, size: 45, required: true }
email: { type: varchar, size: 100, required: true }
topic: { type: varchar, size: 255, required: true }
message: { type: longvarchar, required: true }
created_at:
On lance rapidement la tâche de création de la table et des objets ORM associés :
$ ./symfony propel:build-all $ ./symfony cc
Maintenant, allons faire un tour dans le répertoire lib/model pour voir ce qui a été généré. Surprise, des objets de formulaires ont été automatiquement créés pour nous !
Jetons un oeil plus particulièrement au fichier lib/form/base/BaseContactDemandForm.class.php :
<?php class BaseContactDemandForm extends BaseFormPropel { public function setup() { $this->setWidgets(array( 'id' => new sfWidgetFormInputHidden(), 'name' => new sfWidgetFormInput(), 'email' => new sfWidgetFormInput(), 'topic' => new sfWidgetFormInput(), 'message' => new sfWidgetFormTextarea(), 'created_at' => new sfWidgetFormDateTime(), )); $this->setValidators(array( 'id' => new sfValidatorPropelChoice(array('model' => 'ContactDemand', 'column' => 'Id', 'required' => false)), 'name' => new sfValidatorString(), 'email' => new sfValidatorString(), 'topic' => new sfValidatorString(), 'message' => new sfValidatorString(), 'created_at' => new sfValidatorDateTime(array('required' => false)), )); $this->widgetSchema->setNameFormat('contact_demand[%s]'); $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema); parent::setup(); } public function getModelName() { return 'ContactDemand'; } }
Cela ne vous rappelle rien ? C'est presque quasiment ce que nous avions écrit manuellement précédemment dans notre classe ContactForm. On notera également la présence dans le fichier lib/form/ContactDemandForm.class.php de la classe ContactDemandForm, cette dernière héritant de BaseContactDemandForm.class.php, ce qui nous permettra de surcharger tout ou partie de ses méthodes pour adapter le formulaire généré à nos besoins.
En l'occurrence, il nous faut adapter un peu la méthode configure() pour retrouver notre sélecteur de sujets et réappliquer nos validateurs. Voici le code de la classe ContactDemandForm modifiée en conséquence :
<?php class ContactDemandForm extends BaseContactDemandForm { public function configure() { // Widgets $topics = sfConfig::get('app_contact_topics', array()); $this->setWidgets(array( 'id' => new sfWidgetFormInputHidden(), 'topic' => new sfWidgetFormSelect(array('choices' => $topics)), 'name' => new sfWidgetFormInput(), 'email' => new sfWidgetFormInput(), 'message' => new sfWidgetFormTextarea() )); // Validators $this->setValidators(array( 'id' => new sfValidatorPropelChoice(array('model' => 'ContactDemand', 'column' => 'Id', 'required' => false)), 'topic' => new sfValidatorRegex(array('pattern' => '/[a-z_]/')), 'name' => new sfValidatorString(array('min_length' => 2, 'max_length' => 45)), 'email' => new sfValidatorAnd(array(new sfValidatorEmail(), new sfValidatorString(array('max_length' => 100)))), 'message' => new sfValidatorString(array('min_length' => 10)), 'created_at' => new sfValidatorDateTime(array('required' => false)), )); $this->widgetSchema->setNameFormat('contact_demand[%s]'); $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema); } }
On va maintenant modifier notre action pour prendre en compte notre nouvelle classe de formulaire liée à notre objet Propel :
<?php class contactActions extends sfActions { public function executeIndex(sfWebRequest $request) { $form = new ContactDemandForm(); if ($request->isMethod('post')) // If HTTP method is POST { // Bind submitted values to the contact form instance $form->bind($request->getParameter('contact_demand')); // Validate the form if ($form->isValid()) { // Save submitted values in form's ContactDemand object $form->save(); // Then redirect user to the homepage with a one-shot message $this->getUser()->setFlash('notice', 'Message sent'); $this->redirect('@homepage'); } } // Publish form instance to the view $this->form = $form; } }
Ainsi, un simple $form->save() nous permet de persister en base les données soumises par l'utilisateur au travers du formulaire autogénéré. Un sacré gain de productivité en phase de prototypage, assurement !
Voilà, ce n'est bien évidemment là qu'une infime partie de ce que peut faire le nouveau système de gestion de formulaires de Symfony 1.1, mais c'est un peu à reculons que l'on retourne à l'ancien système 
[1] Nous ne créons pas de route pour le moment, même si ce serait là une bonne pratique, afin de ne pas surcharger inutilement le contenu de ce tutorial, déjà bien assez dense comme ça
[2] On aurait bien entendu pu proposer des valeurs par défaut.
[3] Le mécanisme de génération de code devrait permettre de proposer facilement la même fonctionnalité pour Doctrine prochainement.
[4] Je vous laisse le soin de vous référer au tutoriel existant sur ce même blog
samedi 12 janvier 2008
Par NiKo le samedi 12 janvier 2008, 20:56 - Dev
Ah la la. C'est assez rare pour être souligné, mais je viens de me battre avec Symfony pendant près de deux heures avec un problème assez déroutant de prime abord : lorsque dans une action vous faites quelque chose d'aussi anodin que ceci :
public function executeBar() { try { // Some stuff here, if successful redirect user to somewhere else $this->setFlash('notice', 'Action was successful'); $this->redirect('@whatever_route'); } catch (Exception $e) { $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude'); $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err'); return sfView::SUCCESS; } }
Et bien dans ce cas là, la redirection s'opère MAIS l'ensemble du rendu sera tout de même produit et envoyé au navigateur [1] - ce qui peut s'avérer très couteux sur un site internet au final [2]. La raison en est très simple, la méthode redirect() de la classe sfActions met fin à l'execution par ce moyen que l'on peut qualifier de hardi :
public function redirect($url, $statusCode = 302) { $url = $this->getController()->genUrl($url, true); if (sfConfig::get('sf_logging_enabled')) { $this->getContext()->getLogger()->info('{sfAction} redirect to "'.$url.'"'); } $this->getController()->redirect($url, 0, $statusCode); throw new sfStopException(); }
Oui, vous avez bien lu, on interrompt le script en levant une exception, ici de type sfStopException. Le problème, c'est que dans mon exemple précédent, la méthode redirect() est appellée dans un bloc try { } catch { }, et donc l'exception levée est interceptée et l'action n'est au final pas stoppée. Vicieux, hein ?
Pour régler le problème, on peut par exemple toujours effectuer ses appels à la méthode redirect() en dehors d'un block try { } catch { } [3], ou encore tester le type de l'exception levée. Dans notre exemple, cette dernière solution ressemblerait à ça :
public function executeFoo() { try { // Some stuff here, if successful redirect user to somewhere else /// ... $this->setFlash('notice', 'Action was successful'); $this->redirect('@whatever_route'); } catch (sfStopException $e) { return sfView::HEADER_ONLY; } catch (Exception $e) { $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude'); $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err'); return sfView::SUCCESS; } }
C'est pas super sexy, mais ça fonctionne, et ça a le mérite de m'inspirer deux morales à cette histoire :
Edit: Je m'exprime mal, c'est pas super cracra, c'est juste que ça introduit une petite complexité supplémentaire. Mais l'utilité de la chose est bien entendu totalement avérée si on a besoin d'effectuer des opérations particulières avant la fin du script ( ce qui est rarement le cas, enfin chez moi).
[1] Avec tout ce que ça comporte de requête SQL et de templates calculés pour rien
[2] Et oui bien sûr, faire un redirect() dans un bloc try catch c'est pas forcément le meilleur endroit, mais c'est teeeellement pratique 
[3] Qui sera donc exécuté de toute façon si aucune exception n'est levée.
lundi 5 novembre 2007
Par NiKo le lundi 5 novembre 2007, 21:33 - Divers
Il est suffisamment rare de rencontrer un passionné du web comme David Larlet pour se priver du luxe de lui faire un peu de pub quand il décide de se mettre à son compte
Dont acte, si vous désirez confier la conception et la réalisation de votre projet web à un professionnel amoureux des standards et bonnes pratiques du web et prompt à s'impliquer à vos côtés dans toutes les phases de l'accompagnement de votre projet, je vous engage à prendre contact avec lui de ce pas.
jeudi 1 novembre 2007
Par NiKo le jeudi 1 novembre 2007, 10:26 - Dev
Suite à l'émergence des frameworks web, beaucoup d'équipes de développement ont décidé de leur utilisation sans toujours bien réaliser les tenants et aboutissants liés la démarche, croyant souvent avoir enfin trouvé une méthode miracle pour produire vite et bien. Il peut en résulter de sévères déconvenues, quel que soit le framework, le langage ou la plateforme retenus.
Concernant Symfony, il en va de même ; et si on peut bien entendu trouver énormément d'avantages à son utilisation sur un projet, il faut également bien avoir conscience des contraintes qu'un développement sur sa base implique, sous peine de se retrouver dans le mur assez rapidement.
Il est immédiatement tentant de retenir Symfony pour tout type de projet tellement il est agréable de développer sur sa base. Cependant, pourquoi systématiquement réinventer une roue qui tourne peut-être déjà fort bien ailleurs ? L'idée ici est de s'interroger sur la réelle nécessité de recourir à un développement spécifique ; en effet, même si coder en Symfony est très encadré, il n'empêche que la logique métier est entièrement à définir par l'équipe de développement [1]. Plus particulièrement concernant les problématique de gestion de contenus, le besoin métier sur le projet est-il suffisamment conséquent, ou un CMS comme Drupal, SPIP, ezPublish ou Joomla couvre t-il nativement l'ensemble du périmètre fonctionnel cible ? [2]
Un développement spécifique introduira le plus souvent beaucoup plus d'exigences, de compétences et de compléxité qu'une intégration basée sur un outil de gestion de contenus autonome existant (et digne de ce nom). L'idée est bel et bien de renoncer à se faire plaisir à tout prix pour se situer au plus près de la réalité du besoin.
Bien entendu, je me fais aussi ici l'avocat du diable. Pour avoir joué avec les principaux CMS PHP open source du marché et connaissant la propension naturelle d'un client à enrichir au gré de l'avancement projet le périmètre fonctionnel souhaité [3], je préfère allègrement à titre personnel me baser sur un framework comme Symfony afin de rester agile et parer à toute éventualité. Mais je sais aussi quelles sont mes compétences réelles sur le sujet, et dès qu'une équipe dont je ne cerne pas le niveau entre en ligne de compte, généralement les problèmes commencent. Ça tombe bien, c'est justement l'objet du prochain chapitre
Non, Symfony ne transformera pas magiquement un mauvais développeur en bon développeur... même s'il peut y contribuer à terme
Plus sérieusement, le but réel de l'utilisation d'un framework est bel est bien de vous rendre plus efficace et productif, certainement pas de vous compliquer la vie ou de vous faire perdre du temps.
Il faut bien prendre conscience que le temps de montée en compétence sur l'utilisation du framework - déjà naturellement exigeante - requière également pour certains une montée en compétence en programmation tout court. Et cette dernière, si elle peut se faire sur un projet, peut également allègrement le plomber. Un développeur débutant bidouilleur PHP mettra fatalement plus de temps qu'un codeur expérimenté à appréhender l'ensemble des possibilités introduites par PHP5, la programmation orientée objet, les motifs de conception, mais aussi le respect des bonnes pratiques notamment liées au travail collaboratif ou que sais-je encore.
Le risque à court terme est de voir le code du projet grevé dans sa qualité et sa maintenabilité. À moins bien entendu de prendre en compte en amont cette charge inhérente à la formation, mais on connait tous la réalité professionnelle et commerciale du milieu qui est le notre
Oui, Symfony fait la part belle aux conventions et prémâche énormément le travail redondant à tout projet de type web. La vie des (bons) développeurs est grandement facilitée, et on peut vraiment gagner rapidement beaucoup de temps. Mais une grave erreur serait de sous-estimer la charge liée à l'organisation et la gestion de la vie du projet.
Par exemple, ce n'est pas en mettant plus de développeurs sur un projet Symfony (ou autre d'ailleurs) que celui-ci sera développé plus vite. Au contraire, même ; tout codeur avec un tant soit peu d'expérience professionnelle a déjà rencontré ce type de cas de figure : on vend un projet de 100 jours de développement, on se fixe un retroplanning ambitieux avec une mise en ligne à 20 jours ouvrés, et on staffe donc arithmétiquement cinq développeurs à plein temps en pensant que le résultat sera totalement équivalent au travail qu'aurait fourni un unique développeur en 100 jours de développement pour concevoir l'intégralité du code de l'application résultante.
Bien entendu, c'est illusoire et généralement, le projet se termine sur des dépassements conséquents et le mécontentement du client [4]. Et pour cause, la déperdition d'énergie utilisée à la communication sur le projet est fonction du nombre d'acteurs présents sur ce dernier. Et on peut staffer trois chefs de projet à plein temps pour canaliser tout ça, c'est d'une part économiquement peu viable et d'autre part totalement inefficace, ces derniers devant perdre également beaucoup de temps à se synchroniser entre eux, puis avec les membres de l'équipe.
Non, Symfony n'est pas le remède miracle aux lacunes organisationnelles des structures en charge de la réalisation d'un projet, mais bien un outil exigeant qu'il faut savoir appréhender de la bonne façon en prenant en compte le plus en amont possible ces problématiques. Le gain réel et indiscutable d'efficacité apporté par l'utilisation d'un framework comme Symfony est à ce prix
[1] Je n'ose pas évoquer ici la notion d'architecte logiciel connaissant la réalité moyenne du monde PHP.
[2] Pour nuancer ce propos, de plus en plus de plugins Symfony tendent à apparaitre pour couvrir ce type de besoins fonctionnels.
[3] Le premier qui me parle du sacrosaint cahier des charges contractuel, je le mords.
[4] Sans parler de la charge de stress portée sur l'équipe, qui du coup va saloper le boulot pour livrer au plus vite.
mercredi 3 octobre 2007
Par NiKo le mercredi 3 octobre 2007, 11:31 - Dev
Pour un projet, je suis en train d'utiliser la librairie javascript jQuery dans Symfony, en lieu et place du couple prototype et scripaculous dont je vous avait déjà parlé.
L'idée est ici de ne pas avoir à utiliser les helpers fournis par Symfony (qui mettent en oeuvre exclusivement Scriptaculous) et ainsi d'éviter d'utiliser les deux librairies simultanément sur le projet, mais aussi de décoreller le code javascript des templates et de favoriser une meilleure dégradabilité de ce dernier.
Par exemple, au lieu d'utiliser la fonction link_to_remote() dans notre template, on peut tout à fait imaginer d'employer un bon vieux link_to() des familles et de lui appliquer une classe css qu'on va pouvoir cibler depuis jQuery afin d'effectuer un appel AJAX pointant vers l'url présente dans l'attribut href du lien. Avec un exemple, c'est un peu plus clair :
<?php echo link_to('Mon lien', '@maroute?monparam=mavaleur', array('class' => 'ajax_link')) ?>
Dans un fichier javascript (jQuery doit bien entendu être chargé) :
$(document).ready(function() { $('a.ajax_link').click(function() { $.ajax( { type: 'post', url: $(this).attr('href'), success: function(msg) { alert("Résultat: " + msg); } }); return false; } ); });
Avantage supplémentaire, vous continuez à bénéficier du système de routing Symfony (pas d'urls en dur dans les fichiers javascripts externalisés.)
Là où Symfony va également nous aider, c'est au travers de sa gestion native de la décoration d'une vue en fonction du type d'appel HTTP : le framework va detecter si l'action a été appelée ou non depuis une requête XmlHttpRequest et, si c'est le cas, décorer la vue avec le layout global de l'application et donc présenter à vos utilisateur le résultat escompté, qu'ils aient activé javascript ou non pour surfer sur votre site.
Si vous désirez mettre à jour un élément de l'arbre DOM avec le contenu reçu d'une requête Ajax, voici une autre petite astuce ; on va utiliser une ancre dans l'url et s'en servir comme argument décrivant l'id DOM qu'on veut mettre à jour :
<?php echo link_to('Mon lien', '@maroute?monparam=mavaleur#mon_div', array('class' => 'ajax_link')) ?> <div id="mon_div" style="display:none"></div>
Et en javascript :
$(document).ready(function() { $('a.ajax_link').click(function() { var href = $(this).attr('href'); var target = href.substring(href.lastIndexOf('#'), href.length); $.ajax( { type: 'post', url: href, success: function(msg) { if ($(target)) { $(target).html(msg).show('slow'); } } } ); return false; } ); });
Note : on aurait pu aussi détourner l'attribut target à cette fin mais ce dernier n'est pas valide en XHTML strict.
Bien entendu, ceci n'est qu'un microscopique aperçu de l'étendu des possibilités de jQuery et de son intégration possible avec Symfony (ou d'autre frameworks et langages, bien entendu.)
dimanche 19 août 2007
Par NiKo le dimanche 19 août 2007, 13:04 - Dev
Pour les besoins du boulot, j'ai du me mettre à Flex, le framework d'Adobe orienté RIA en Flash.
Je pensais que mon passé de flasheur m'aiderait à monter rapidement en compétence sur cette techno, ben non : c'est tout à fait autre chose que ce que je connaissais de l'IDE traditionnel, dont je m'étais arrêté à la version 8. Avec Flex on a affaire à un framework complet de génération d'interfaces riches basées sur l'emploi de composants décrits et paramétrés en XML et de la dernière mouture du langage ActionScript en version 3. Quelques exemples d'applications réalisées avec Flex sont disponibles, et pour certaines, ça en jette carrément.
La description des interfaces s'opère au moyen du langage MXML[1], basé sur XML un peu comme ce que proposent XUL ou XAML ou même XHTML (qui reste une implémentation particulière et standardisée d'XML). Deux types principaux de composants sont disponibles : les conteneurs (boîtes, panneaux, fenêtres, etc.) et les éléments de contrôle (champs texte, listes, datagrids, tree, etc.)
Le nombre de conteneurs et de contrôles est impressionnant, on se prend à rêver de la même richesse en HTML [2]. La plupart des composants sont visibles sur l'explorateur de composants Flex, sur le site d'Adobe. Et le meilleur reste sans doute à venir quand on voit le catalogue de composants supplémentaires open source comme ceux du projet FlexLib...
Le format généré après compilation d'un ensemble de fichiers MXML constituant une application Flex est le SWF, le format natif d'Adobe Flash, lisible par tout bon Flash Player 9 qui se respecte, implanté sur plus de 80% du parc machines desktop mondial d'après les dernières statistiques disponibles sur le site d'Adobe.
Voila un exemple de code MXML décrivant l'interface d'une application simpliste :
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Panel title="Dire bonjour" x="10" y="10" layout="absolute" width="303"> <mx:TextInput id="firstname" x="10" y="10"/> <mx:Button label="Dire bonjour" click="result.text='Bonjour, '+firstname.text" x="178" y="10"/> <mx:Label id="result" x="10" y="40" width="265"/> </mx:Panel> </mx:Application>
Le code est assez parlant, mais voici quelques éléments significatifs :
mx, ce qui nous permettra d'utiliser les composants natifs de FlexPanel contenant trois contrôles :
InputText, champs de saisie textuelleButton, un bouton d'actionLabel, un champs de texte potentiellement dynamiqueid qui doit être unique si renseigné ; il permet de référencer facilement un élément de l'arbre DOMDans l'exemple précédent, on voit que les styles sont appliqués sous forme d'attributs XML. C'est une solution pratique à court terme mais qui peut rapidement s'avérer problématique à maintenir dès que votre application grossit. Aussi, pour séparer la couche de présentation de la description des contenus, tout comme en HTML, Flex permet l'utilisation de feuilles de styles CSS embarquées ou externalisées. Beaucoup de propriétés CSS ont du être créées ou adaptées aux spécificités du balisage MXML et des composants proposés, mais le résultat est une grande souplesse d'utilisation et une large palette de mise en forme disponible. Pour preuve, un petit tour du côté de l'explorateur de styles Flex s'impose.
ActionScript 3 est l'évolution logique des précédentes versions, étendant le périmètre fonctionnel et accentuant son caractère professionnel, notamment dans l'implémentation objet, les types natifs et l'organisation en packages des différents objets de programmation.
Une des grandes forces de Flex à mes yeux est la simplicité avec laquelle on peut créer ses propres composants en héritant de composants basiques préexistants et de les manipuler via son propre espace de noms. Par exemple, la création d'un composant dérivé d'un formulaire présentant un champs de login/mot de passe donne à peu près ceci :
<?xml version="1.0" encoding="utf-8"?> <mx:Form xmlns:mx="http://www.adobe.com/2006/mxml" width="280" height="105"> <mx:FormItem label="Login"> <mx:TextInput id="username"/> </mx:FormItem> <mx:FormItem label="Mot de passe"> <mx:TextInput id="password" displayAsPassword="true"/> </mx:FormItem> <mx:FormItem> <mx:Button label="Connexion"/> </mx:FormItem> </mx:Form>
Si on nomme notre fichier de composant LoginForm.mxml et qu'on le stocke dans le répertoire ./components de notre projet Flex, on va pouvoir l'utiliser de la façon suivante dans une application :
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:niko="components.*" layout="absolute"> <mx:Panel title="Connexion"> <niko:LoginForm id="loginform"/> </mx:Panel> </mx:Application>
On a déclaré un nouvel espace de noms, ici niko (mais on aurait pu mettre ce qu'on veut) pointant vers les fichiers sous le répertoire components du projet. Simple, non ? En tout cas, cela devient un jeu d'enfant de produire des composants réutilisables.
Flex propose trois modes d'accès aux données distantes, par le biais de trois composants :
HTTPService, comme son nom l'indique, permet d'effectuer des requêtes HTTP sur une url et d'en récupérer la réponse. Un objet bien pratique quand on veut s'interfacer avec une architecture REST, par exemple.WebService permet de s'interfacer avec un webservice au format WSDL via SOAP. Quand on dispose de tels service, c'est un plaisir de se baser dessus depuis Flex puisqu'on a qu'à réferencer les méthodes à utiliser et les déclencher depuis leur référence.RemoteObject, implémentation du protocole RPC dans Flex, pendant Flash/ActionScript du RMI en Java. Comme je fais peu de Java, j'ai tendance à plutôt utiliser AMFPHP[3] pour publier mes services en utilisant PHP. Un très bon tuto de mise en oeuvre du couple AMFPHP/Flex se chargera d'illustrer le concept plus efficacement que je ne le fais ici.Adobe propose un IDE dédié à la réalisation d'applications Flex, FlexBuilder. Cet outil, basé sur le célebrissime Eclipse, permet de disposer d'un environnement complet de développement comprenant entre autres un éditeur de code (MXML en mode source/wysiwyg, ActionScript, CSS, etc.), un débogueur avancé à la Java, un gestionnaire de projets, la compilation automatique et surtout un accès à l'immense catalogue des plugins Eclipse. D'ailleurs, FlexBuilder est également disponible sous la forme d'un plugin à installer sur une instance d'Eclipse existante : de quoi travailler sur vos projets Flex/PHP de façon centralisée, par exemple.
Inconvénient majeur de cet outil, il est payant. Et coûte relativement cher, puisque proposé aux alentours de 500€. Néanmoins, le SDK de Flex étant gratuit, vous pouvez tout à fait vous passer de FlexBuilder et compiler vos applications à la main. Une bonne nouvelle ne venant jamais seule, Adobe a décidé de publier la prochaine mouture du framework sous licence libre [4], aussi nous devrions voir fleurir des alternatives à FlexBuilder et assister à un taux d'adoption plus conséquent de la technologie.
Au vu de l'étendue fonctionnelle de Flex et des différents formats de fichiers mis en oeuvre ainsi que de leurs interactions potentielles, il est clair que maintenir la moindre petite application peut vite relever du cauchemar les développements avançant. Pour faire face à cette problématique, Adobe propose un surframework du nom de Cairngorm mettant en oeuvre les bonnes pratiques d'architecture logicielle en implémentant le motif de conception MVC bien connu des utilisateurs de frameworks de développement rapide orientés web.
Même si le projet semble extrêmement intéressant, je n'ai pas encore pour l'heure pu jouer avec.
Pour l'heure et après avoir pas mal galéré tâtonné avec l'outil au début, je dois reconnaître maintenant et avec un peu de recul que c'est assez efficace. C'est relativement déstabilisant pour quelqu'un qui comme moi avait l'habitude de l'IDE Flash Authoring classique, mais au final FlexBuilder semble beaucoup plus sérieux pour tout ce qui concerne la programmation et l'organisation des fichiers (Eclipse oblige.) Même le templating y gagne à mon sens, mais par contre impossible de faire de la création graphique avancée directement dans FlexBuilder, l'outil n'est clairement pas l'ami des infographistes de vocation.
Pour enfoncer le clou, j'ai pu comparer l'utilisation de Flex et de XUL, ayant enchaîné deux projets coup sur coup les mettant en oeuvre. L'excellente documentation de Flex et la richesse des outils gravitant autour de la techno font que pour l'heure Flex me semble l'un des meilleurs choix pour développer une RIA, si l'on écarte le couple HTML/Ajax qui garde une toujours une place de choix dans mon arsenal webdeuzéroesque
[1] Je ne sais pas à quoi correspond la lettre M de l'acronyme, Macromedia sans doute.
[2] En attendant HTML5, les antiflash pourront aller zieuter du côté d'extjs ou de YUI.
[3] Attention à bien utiliser la dernière version 1.9 beta compatible avec Flex2
[4] Sous licence MPL plus précisément.
« billets précédents - page 1 de 3