Langages de scripts, bases de données et
développement Web
gilles.hunault "at" univ-angers.fr
1. Langages de scripts, développement rapide et développement Web
Le grand intérêt des langages de scripts interprétés est de ne pas passer par une phase de compilation explicite mais plutôt d'être compilés JIT (just in time). Ce n'est donc pas un exécutable binaire qu'on transmet, mais le code-source, directement, une fois l'interpréteur du langage installé sur chaque OS où on veut l'utiliser. Chacun peut donc lire le code du programme -- et le modifier éventuellement --, comme en open source.
Toutefois, le développement associé aux langages de scripts est souvent un développement par morceaux, à partir d'un petit noyau de code, notamment lorsque le problème est à court à résoudre, comme par exemple le nombre de lignes vides et de commentaires dans un texte : voir l'archive des programmes écrits en cours. Ce genre de programmation est cohérent avec l'ajout progressif de fonctionnalités et le chargement "à la carte" de modules ou l'utilisation de l'interpréteur en mode interactif.
L'évolution des langages de scripts suit un peu cette tendance et malheureusement Python et Ruby ont progressé avec des versions légèrement incompatibles mais incompatibles quand même. Du coup, tous les "beaux" modules de Python 2.7.3 ne sont pas disponibles pour Python 3.3.0, et notamment la PIL (Python Imaging Library) ainsi que le fameux framework de développement django. Il faut donc souvent installer et savoir gérer plusieurs versions de l'interpréteur et de ses modules. Ainsi, il faut utiliser pip-2.7 et pip-3.3 alternativement pour profiter de pip. De même, pour Ruby, il faut passer par rvm et choisir sa version de ruby avant d'utiliser les outils associés, sous peine d'obtenir un message comme rake/rdoctask deprecated et un "aborted" de rake db:migrate quand on utilise rails 3.0.5 au lieu de 3.0.10 (comme indiqué malheureusement dans le tuteur français frenchrails). Oui, mais si quand on tape rvm en console, il y a marqué rvm is not a function ? Réponse : il faut penser à exécuter source ~/.rvm/scripts/rvm avant d'exécuter la commande rvm.
On comprend donc ici que l'installation et la gestion des interpréteurs et de leurs modules rejoint parfois la «prise de tête» qui survient à la compilation lorsqu'il manque une dépendance qui elle-même dépend d'une ressource incompatible with the current header et toutes ces bonnes petites choses qui font que tout ne fonctionne pas toujours bien du premier coup. Heureusement, les forums d'utilisateurs sont là pour aider à dépanner...
Les derniers-nés des langages de scripts que sont Ruby et Python ont grandi avec la programmation objets et le web. Il est donc normal que ces langages soient adaptés au développement de maquettes ou de prototypes d'applications Web sur serveur. Leur coté interactif avec configuration à la volée les rend particulièrement efficaces et rapidement déployables, sans compter la présence d'outils et de modules pour développer des tests unitaires, des tests d'intégration, des tests de déploiement, des tests de "clic" et des tests de charge... A ce titre, sinatra est remarquable de concision...
Pour les interfaces lignes de commande "dopées" par Tk, il existe même un tutorial en quatre langages (Tcl, Perl, Python, Ruby).. mais qui utilise les langages Active*. On viendra donc les installer, y compris pour Linux (via sudo sh install.sh pour chaque tgz décompressé) à partir du site activestate. Pour éviter des erreurs de copier coller, l'archive tk4l.zip vous fournit tous les programmes présentés...
Si on analyse ce que sont les applications Web, on se rend compte qu'elles mettent en jeu en général au moins cinq langages dont deux langages de description (Html, Css) et trois langages de programmation (scripts server, bases de de données, javascript). Il n'est pas souhaitable qu'un développeur mélange tous ces langages et c'est pourquoi il y a des systèmes de patrons, modèles et gabarits pour les pages web, des scripts de création automatique avec des "templates" au niveau de Html et Css. Pour les bases de données, l'ORM permet de masquer le code SQL au profit d'appels de méthodes_objets. Enfin, la liaison directe entre client et serveur (ou indirecte via Ajax) passe souvent par l'envoi de structures sérialisées (en texte simple ou en Json, Xml, Yaml...) ce qui nécessite de la part du programmeur un fort niveau de connaissances hétérogènes...
Il y a des techniques classiques pour écrire des sites, c'est-à-dire pour écrire du code qui génére des pages :
par exemple on peut écrire des pages séparées, indépendantes les unes des autres et mettre des liens "en dur" ;
on peut utiliser une page unique avec des paramètres en mode GET ou POST pour guider la navigation ;
on peut mettre en place une architecture REST pour "mapper" les ressources avec les URL.
Comme pour tout développement, programmer des sites Web impose de tout tester. En plus des tests unitaires, des tests d'intégration, il faut aussi prévoir des tests de charge s'il doit y avoir des milliers d'utilisateurs, et des tests de "clic" pour simuler des actions utilisateurs, et vérifier que la page est bien chargée ou, avec Ajax, que telle section est bien apparue.
Les frameworks de développement répondent à ces exigences et viennent simplifier (au moins au début) de nombreuses tâches, faciliter l'ORM, implémenter une architecture REST et fournir un modèle MVC. Il y a bien sur des frameworks pour tous les langages, que ce soit java, javascript, php... Les divers textes et exercices de ce cours essaieront de présenter quelques-uns des aspects de ces frameworks, étant entendu qu'un "vrai" framework est un outil riche et complexe, qu'il faut de la pratique pour le maitriser (après l'avoir choisi, ce qui n'est pas si simple). Les quelques références et connaissances exposées ici ne seront bien sûr pas suffisantes pour rendre les lecteurs et lectrices totalement compétents et autonomes pour ces frameworks.
Compte-tenu du nombre d'heures de cours et de TP, nous avons retenu les frameworks Django et Ror (Ruby on rails) notamment parce qu'ils sont rapides à installer et que leur tutoriel est assez stable au cours du temps. Il aurait sans doute été intéressant de présenter CakePhp, Symfony et Joomla... A cause de REST, MVC et ORM, il est important de bien connaitre la programmation objet des langages utilisés. Un peu de recul sur Html, Css, Xml, la sérialisation et une inititation à Javascript et Ajax sont donc requis pour bien profiter de ce cours.
2. Langages de scripts, persistance, bases de données et ORM
Une fois des variables et des objets créés en mémoire, la question se pose quant à leur pérennité, leur persistance. On doit parfois les conserver d'un jour à l'autre, les archiver, les sauvegarder ou les transmettre à un autre script, un autre programme ou à un programme-client qui attend des données, par exemple sous Javascript avec AJAX. Il faut donc savoir passer de la mémoire à un format texte, qu'il s'agisse d'un format "construit pour" via XML ou d'un format adapté à la sérialisation (mieux : serialization), ou d'un format de données structurées comme le sont json et yaml. Voici un exemple des possibilités offertes par PHP en la matière : oo_pers.php.
Pour des données plus importantes, les langages de scripts doivent communiquer avec les SGBDR traditionnels, soit en mode query «pur et dur», soit en mode objets avancé, ce que réalise ORM pour les actions CRUD usuelles, mais aussi pour des interrogations plus techniques, ce que nous nommons FCRUD*, où F est mis pour Find et * pour toutes les autres actions. Il est usuel d'utiliser des frameworks de développement pour automatiser ces taches de liaison entre objets et bases de données. Ainsi Ruby utilise activement le patron de conception ActiveRecord dans son framework Ruby on rails via la classe ActiveRecord là où Python utilise SqlAlchemy dans son framework django.
Il faut donc maitriser la définition des fonctions et des objets pour profiter pleinement de ces techniques. Ainsi, on peut consulter les chapitres 7, 11 et 12 du livre de G. Swinnen pour Python et les premiers chapitres de programming ruby 1.9 et de metaprogramming ruby.
L'intérêt de l'ORM est de masquer le code SQL et de fournir des appels de méthodes objets pour exploiter les tables. Voici un mini exemple pour Ruby et un exemple plus soutenu en php pour le framework de développement prado. Il est bien sûr possible de coupler la gestion des données avec la production automatique des formulaires de saisie ou de mise à jour, avec ou sans interface Web. Par exemple pour Ruby, on peut utiliser GladeGUI, qui est une implémentation de glade en Ruby.
Si la technique ORM est utilisable (ou plutôt implémentable) dans tous les langages, les langages de scripts sont particulièrement adaptés à leur maitrise puisqu'il fournissent une console interactive qui permet de comprendre et de tester les objets et les méthodes liées aux bases de données. Cette console sert de boucle REPL qu'on retrouve dans de nombreux langages interprétés (voir repl.it) mais qu'on peut implémenter dans presque tous les langages.
Puisque la technique ORM s'appuie sur les bases de données, il est naturel aujourd'hui (2013) de s'appuyer sur SQLITE3 comme moteur de bases de données, surtout en prototypage d'applications Web. Plus simple que MySql et PostgreSql, sqlite3 n'utilise que des fichiers binaires facilement copiables. Php, Perl, Ruby et Python savent bien sûr dialoguer avec SQLITE3 en cette année 2013.
3. Langages de scripts et le "patron" MVC
Lorsqu'on commence à développer, on écrit souvent un programme élémentaire qui lit, calcule et écrit, comme dans l'algorithme de conversion suivant de pouces en centimètres :
# algorithme de conversion de pouces en centimètres # (lecture au clavier, affichage à l'écran) lire po calculer cm <- po*2.54 écrire po , " pouces font " , cm " centimètres "À un niveau supérieur de développement, on retrouve la même organisation des programmes et applications :
# algorithme général de traitement initialisations() saisies() calculs() affichages() # ou stockages() stockages() # puis affichages()Il s'agit ici d'une organisation logique, conceptuelle et non pas d'une organisation physique, en fichiers, répertoires... Dans le cadre du développement Web, la même problématique (gérer les saisies et autres évènements, calculer, mettre à jour, afficher... ) et la même stratégie (séparer les saisies des traitements, des stockages et des affichages) aboutit à utiliser un patron de conception nommé historiquement MVC mais qui n'était pas conçu pour le Web avec son fonctionnement particulier en mode client (navigateur) et serveur (web).
On trouvera sous les images ci-dessous des liens explicant ou mettant en oeuvre le concept de MVC et dans mvc.py un mini-exemple en Python 2 qui utilise Tk pour les vues.
Puisque MVC est un "concept" ou un patron, un schéma... il n'y a pas une organisation-type des fichiers ni un modèle rigoureux de fonctions et objets à implémenter. C'est pourquoi le concept d'ORM vu précédemment lui est orthogonal (indépendant) dans une certaine terminologie de modélisation. De plus, ce concept peut s'expliquer simplement via la définition des trois mots Modèle, Vue, Controleur ; voir par exemple un premier mini-exemple en PHP, ou ce deuxième mini-exemple toujours en PHP, dont le code source est ici. Mais dès qu'il s'agit de rentrer dans les détails, les choses se compliquent. Surtout pour les projets et applications Web, comme on pourra le lire sur le site codinghorror.com, notamment à cause de http, de la réécriture des URIs, du passage obligé à une base de données...
4. Frameworks de développement et tests de développement pour les langages de scripts
Il est assez facile, lorsqu'on a maitrisé les rudiments d'un langage de programmation, de développer des applications, c'est-à-dire écrire des programmes d'importance. Si on développe professionnellement, on finit par avoir ses habitudes, ses sous-programmes types. Et on utilise souvent aussi des librairies écrites par d'autres professionnels, ce qui signifie qu'on utilise des programmes et des objets des autres. Lorsque ces applications utilisent le Web, il peut être plus ou moins long de les mettre au point, notamment parce qu'il faut pouvoir tester les actions des utilisateurs.
Sans utilisateur, une application Web est assez facile à développer. Prenons l'exemple d'un site qui doit afficher des données météorologiques, sans interaction des internautes. Après la vérification de la possibilité de capturer les données sur le site de Météo France, il est simple de développer un premier mini-prototype sous forme d'un module de lecture des données, disons en Python, comme on pourra le vérifier sur code-weblog.com. A partir de ces données, on construit un modèle des données, ce qui aboutit à une structure de base de données Il reste alors à compléter la partie vue de l'application pour obtenir une application qui tient la route, mais dont l'architecture tient sans sans doute plus du concept Model 2 que du concept MVC.
En cas d'interaction avec les internautes, on retrouve de nombreuses composantes et entre autres la connexion avec les fameux login et password, ce qui induit une table users dans la base de données de l'application, les opérations de création, recherche (et donc lecture), mise à jour et destruction des informations, le fameux CRUD, la pagination des affichages des informations, l'injection dynamique de textes, images, photos et vidéos avec Ajax...
C'est ce qui explique l'apparition des premiers cadriciels d'application (software frameworks) qui utilisent un modèle fixe de site, avec juste des contenus variables (CMS), que ce soit avec une possibilité d'édition dite "riche" ou pas. Les logiciels de gestion de contenus sont très nombreux, si on suit le wiki français qui les organise en plusieurs rubriques sans doute discutables... Deux de ces CMS bien connus et utilisés en France sont Joomla et Spip.
Mais gérer des contenus comme des «nouvelles du front» pour une association ne couvre pas tous les besoins de toutes les entreprises. Aussi a-t-on vu apparaire tout de suite après les premières bibliothèques PHP pour des serveurs de type AMP (A comme serveur Apache, M comme base de données MySql et P comme langage Php), les premiers systèmes à tout faire programmables en PHP, avec une architecture plus ou moins cloisonnée et donc plus ou moins conformes au concept MVC et consor. On trouvera sur le wiki français une longue liste de frameworks pour Php, ce qui montre bien l'engouement pour de tels logiciels. Et, sur le wiki anglais, on trouve dans une même page des frameworks pour de nombreux langages, ainsi qu'une comparaison de divers frameworks pour Php, les plus connus en France étant certainement Zend et Symfony.
Toutefois, PHP n'est sans doute pas un "bon" langage et pour des frameworks objets orientés Web dits rapides ou RAD, le choix s'est porté sur Ruby et Python, notamment avec Rails et Django, même s'il y a de nombreux autres alternatives pour ruby dont sinatra (et padrino?) et pour python dont web2py, flask, bottle... Il existe peu de vrais comparatifs de tous ces frameworks. La première raison est qu'il faudrait définir des critères fins et précis afin de pouvoir les évaluer et les comparer. La seconde est que ces langages changent si vite qu'une comparaison d'un framework en version x serait dépassée au bout de six mois avec l'arrivée de la version x+1.
Comment choisir alors un "bon" framework ? C'est bien sûr une question difficile et selon l'adage «l'usage fait loi», il est classique de choisir un "grand" framework ou un des frameworks les plus cités selon Google. À tout prendre, cela garantit au moins une «certaine pérennité» du framework. Sans compter que :
ces cadriciels sont en général développés par des petites équipes (parfois par un seul programmeur dit "génial") et qu'en conséquence les versions successives ne sont pas toujours compatibles avec une version précédente du framework ou avec une version suivante du langage sous-jacent ;
les développeurs «développent», c'est-à-dire qu'ils écrivent du code plutôt que de la documentation ;
les développements sont souvent en anglais avec des traductions françaises "outdated" ou "has been" (et encore, quand elles existent) ;
l'inter-opérabilité (la compatibilité multi OS) et la prise en charge d'Unicode sont parfois approximatives ;
les drivers ou adaptateurs pour les différents moteurs de base de données ne sont pas toujours disponibles ;
l'ORM qui devrait être partie prenante du framework n'est pas toujours présent ;
la notion de test (unitaire, d'intégration, de charge, de clic...) n'est pas toujours implémentée ;
rien ne garantit que le framework existera encore l'année suivante.
On pourra s'en convaincre en cherchant puis en testant des tutoriels français pour ces frameworks, avec la prise en charge de tous les moteurs de bases de données, de l'ORM, des tests, de l'Unicode...
Le succès de Django (version 1.5 ou suivantes) et de Rails (version 3.1 ou suivantes) s'explique ainsi par le fait que de nombreuses fonctionnalités sont présentes et assez bien documentées, au moins en anglais, que la «philosophie» RAD & DRY y est maitrisée (un script peut "tout" faire, l'ORM est obligatoire, écrire des tests fait partie intégrante du développement, sqlite3 suffit pour le prototypage...), ce qui correspond plus ou moins à des méthodes dites agiles sans compter un certain effet de mode sans doute justifié par le fait que ces cadriciels sont adaptés pour répondre à la "nouvelle technologie" de 2013 (tablettes, smartphones...). Mais bien sûr tout framework qui implémente ces points forts n'est pas à négliger. Ainsi CakePHP se présente comme un Rails à la PHP avec aussi une documentation française...
Retour à la page principale de (gH)
