Reflectiv's blog

Petite réflexion sur le développement web

Le web d'aujourd'hui est beaucoup axé sur des bases d'Ajax, couplés à de nombreux principes tels que KISS, DRY et le design pattern MVC (les principaux).

Maintenant, j'ignore vous, mais appliquer ces différents principes au maximum ouvre les portes de nouvelles complexités, là ou il devrait y avoir de la simplicité.

En effet, en règle générale, je suis confronté à deux principaux problèmes. Je vais vous les exposer ici et proposer une approche dans leur résolution.
Je vous invite à me donner votre avis et votre méthode, afin de parvenir à quelque chose de plus fonctionnel et me sortir de ce casse tête :)

Les moteurs de templates, il en existe beaucoup, notamment en PHP. A vrai dire, PHP lui même est un moteur de template à la base, c'est pour dire !

On peux classifier les moteurs de templates en deux catégories, en fonction du travail effectué : coté client et coté serveur.

Les moteurs de templates côté serveur

La liste est plutôt longue si on veux lister les moteurs de templates, ne serait-ce qu'en PHP. Le mieux est donc d'aller voir la doc de Wikipedia sur les moteurs de templates (en) pour profiter de la liste.

Parmis cette liste, on peux indiquer :

• Smarty : Quand même une référence, même si ce n'est pas mon préféré
• TinyButStrong : Le principal concurrent de Smarty
• H20 : L'implémentation du moteur de template de Django en PHP
• Twig : Similaire au moteur de template de Django

Les moteurs de templates côté client

Il existe peu de moteur de template étant traité côté client en ma connaissance. Leur avantage est de diminuer la consommation cpu du côté serveur. Le gros désavantage est les problèmes de compatibilités lié au différents navigateurs (non c'est pas vrai, je ne pense pas à un navigateur en particulier ! :p)

• Transformations XSL : Le serveur fournis un XML structuré et indique une feuille de style qui fera la transformation du XML en HTML. Son gros avantages et qu'il permet de transformer le XML en plein de format possible (PDF, DOC, etc). Le problème est que la transformation n'est possible que par les navigateurs récents.
• Les templates javascript, tel que JQuery Template ou PURE. Nécéssite l'activation de javascript et ne fonctionne pas pour toutes les pages (il faut au moins une page html qui contienne la structure principale).

Le problème actuel

Le problème actuel est que, pour répondre à une requête, il existe aujourd'hui plusieurs moyens :

• La réponse HTML
• La réponse JSON (pour du js)
• La réponse en XML (pour les webservices)
• ...

L'idée ici est de produire du code côté serveur qui ne se soucie pas du type de réponse. La réponse doit être formulée en fonction du type de demande.

En effet, que le client demande la liste des produits via son navigateur web, via une requête ajax ou via un webservice, le traitement effectué par le serveur sera le même
Seul la réponse change.

Une solution ?

Le but serait donc de proposer une interface de communication uniformisée qui prendrait en entrée le résultat du travail demandé (par exemple la liste des produits) pour la retourner dans le format attendu par la demande, peu importe cette demande.

Concrètement, cela serait possible via l'utilisation d'un wrapper autour de la couche de réponse du framework côté serveur. Au lieu de retourner la réponse tel que :

echo $oTemplate->render ();

vous faites un :

echo new ResponseWrapper ($oTemplate->render ());

par exemple.

Ensuite, il ne resterait plus qu'à mettre en place différentes classes par type de sortie que l'on veux. Cela pousse le vice à pouvoir proposer une réponse en .doc ou .pdf sans avoir à modifier (ou très légèrement) le code métier !

XSLT est un début de cette approche.
L'idée d'un tel moteur de template est excellente, mais pas encore totalement au point.
Entre autres, IE interprète des balises à sa façon et la compréhension de la structure d'un élément xsl est assez ... tordue :p

De plus, outre des possibilités de formatage au niveau des sorties (html, pdf, doc), la réponse est quand même limitée : le format nécéssaire en entrée DOIT ÊTRE de l'XML.

Donc à moins d'anticiper son travail en webservice et de faire tourner tous son code autour (notamment l'interprétation du xml par le javascript), l'utilisation du XML en tant que réponse limite quand même le type de réponse (et javascript préfère quand même le json ;)).

(En plus le traitement du xml avec PHP via DOMDocument est assez longue et nécéssite beaucoup d'instance :p)

Conclusion

Voilà, c'était mon point de vue sur la chose, quel est le vôtre ? qu'en pensez-vous ? comment faites-vous ? Je serai ravis de le savoir :)

Posted by Cyril Nicodème 

Django en serveur - Sommaire : Site en Python (Django) sous Apache avec mod_python.

(Voici la suite de ma petite série "faire mumuse avec python sur son serveur".)

Lorsque j'ai parlé du framework python Django, beaucoup d'entre vous m'ont fait la réfléxion du :

Ça à l'air cool (ça l'est ! :p), mais la dernière fois que j'ai tenté de faire marcher python avec apache, ça a été l'enfer !

Ce jour est révolu :) Bon, sur le site de Django, ils conseillent d'utiliser mod_wsgi, mais pour ce tutoriel, nous utiliserons mod_python.

Donc tout d'abord, nous allons l'installer (méthode pour Debian) :

apt-get install libapache2-mod-python

Ensuite, il va falloir l'activer :

a2enmod python

ou équivalent :

ln -s /etc/apache2/mods-available/python.load /etc/apache2/mods-enabled/

Ensuite, il va falloir créer un VirtualHost qui indiquera à Apache que pour ce domaine, il faut utiliser python. Voici un exemple de VirtualHost spécifique à Django :

<VirtualHost *:80>
        ServerAdmin postmaster@[domain].tld
        ServerName www.[domain].tld
        ServerAlias [domain].tld
        DocumentRoot /var/www/[domain]/www/[domain]

        ErrorLog /var/log/apache2/[domain]_error.log
        LogLevel warn
        CustomLog /var/log/apache2/[domain]_access.log combined
        ServerSignature Off

        <Location "/">
                SetHandler mod_python
                PythonHandler django.core.handlers.modpython
                SetEnv DJANGO_SETTINGS_MODULE [nom_du_projet_django].settings
                PythonPath "['/var/www/[domain]/www/'] + sys.path"
                PythonAutoReload Off
                PythonDebug Off
        </Location>
 
        Alias /media "/var/www/[domain]/www/media"
        <Location "/media/">
                SetHandler None
        </Location>
 
        Alias /static "/var/www/[domain]/www/static"
        <Location "/static/">
                SetHandler None
        </Location>
 
        <LocationMatch "\.(jpg|gif|png)$">
                SetHandler None
        </LocationMatch>
</VirtualHost>

Quelques explications s'imposent. Pour mes projets Django, j'ai choisis de faire un structure simple. Dans le dossier de mon projet (appelons le "domain"), j'ai le nom du sous-domaine (ici, www), et dedans, je crée trois dossiers :

• [domain] (le même nom que son dossier parent aka le nom du projet) : il contiendra le code Django
• static : il contiendra tous les fichiers nécéssaire au site : css, js, images, etc
• template : il contient les templates utilisés par Django

Du coup, le fichier de configuration semble un peu plus clair : on définis un Handler de type python pour le répertoire qui contient le code python (/var/www/[domain]/www/[domain]), puis on définis un Handler null (donc aucune interprétation d'un quelconque code) pour les autres dossiers (media et static).

Maintenant, vous vous demandez à quoi sert "media".

En fait, ce répertoire est un liens symbolique que nous allons créer, et qui pointe sur le module admin de Django. En effet, dans la configuration actuelle, si vous tentez d'accéder à l'admin (en ajoutant un /admin/ sur l'url), vous verrez que les images, le style et le javascript ne sont pas présents.

Logique ! Comment apache peux deviner d'où ils viennent ?

Donc pour que notre admin soit fonctionnel, il faut faire un lien symbolique du module admin à notre projet (en supposant que vous avez installez Django comme indiquez dans notre précédent article) :

ln -s /opt/django/django/contrib/admin/media/ /var/www/[domain]/www/media

Du coup, la configuration dans votre VirtualHost prendra aussi effet pour ce répertoire.

Voilà !

Vous n'avez plus qu'à redémarrer, et si votre fichier settings.py de votre projet est correct (notamment au niveau des répertoires ;)), votre site devrait-être accessible !

Posted by Cyril Nicodème 

Why the form validation are in the View part ?

The question is quite clear and I'm going to explain my point of view.

If you take a look at Struts or JSF,and I'm sure, for a lots of others frameworks out there, the form verification are made in the View side.

For example, this is a wrong method (IMHO) used by JSF templates :

<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<f:view>
   <h:form>
      <h:outputText value="Name: "/>
         <h:inputText id="name" required="true" maxlength="20" value="#{user.name}">
            <f:validateLength minimum="3" maximum="20"/>
         </h:inputText>
         <h:message for="name" style="color: red"/>
         <h:commandButton value="Submit" action="success"/>
      <h:form>
</f:view>

The point I want to raise is the fact that it's generally the job of the web designer to make the template, the forms, but NOT to make the verifications !

Yes he need to know which value is needed, eventually which type is waited (for implementing nice date picker for example), but not to test if the string is too short or too long, if it's an email, etc.

The side that must handle this kind of operation must be the Controller, that know which type a field must be. Eventually, the Model side can impose its structure to the controller, but never the View side ! A webdesigner must never impose the structure of the data. Right ?

Ok now everyone is boiling about what javascript is able to, and I totally agree with that, but with restrictions.

Client-side verifications must be implemented only to improve user experience. Never forget that javascript can be disabled !

But it's a great idea to tell at your webdesigner the constraints for the form in the fact that he could implement a client-side verification, and then, your controller will do the server-side (final) verification, in case javascript is disabled, or some bad guy try to play with your code :p

I would be pleased to know your opinion about that :)

Posted by Cyril Nicodème 

[Design] - Todays news (20/10/2008)

Aujourd'hui, plusieurs liens sympas dans divers domaines.

Commençons par 60 Template et Designs gratuit pour vos sites, suivit de près par 25 bon designs qui inspirent, pour finir sur 20 sites web qui vont vous aider à maitriser les interafaces utilisateurs.

Ce dernier point me permet de faire une jolie transition sur une séries de tutoriaux pour débuter en html & css, ainsi que 66 liens pour apprendre les bases du web design.

Je m'orienterai ensuite sur un article expliquant le "MindMapping" à l'aide de la web app MindMeister : Structurer un projet de manière visuelle afin d'avoir la même vue sur le travail, côté client et côté entreprise.

Pour les utilisateurs plus expérimentés, vous trouverez 50 Tutoriels AJAX traitant divers domaine des interfaces utilisateurs ou effet web 2.

Lien connexe : MindMeister

Posted by Cyril Nicodème