CGI – un concept obsolescent?
Cette question on se pose rapidement si on regarde comment on produit du
contenu Web dynamiquement aujourd'hui: AJAX ici, PHP là, jQuery à un autre
endroit – ainsi que plein des autres approches pour compiler et présenter des
contenus au moment de demander la page dont quelques opèrent sur le serveur
(cf. PHP) alors que des autres dépendent des facultés du navigateur Web (comme
AJAX ou jQuery).
PHP y opère bien comme CGI, sauf en cas des fichiers PHP il s'agit des hybrides
du HTML régulier et des régions de script que sont reconnues et exécutées par
le serveur web. Le résultat est présenté conjointement avec les données HTML
résiduelles à la place où la région de était noté.
Dans le cas de CGI il se déroule quelque peu différent qu'en cas de PHP:
Lorsqu'on pose une demande au serveur web que se réfère à un script ou logiciel
CGI, il est démarré par le serveur web. Des éventuelles données à remettre sont
transmises par une variable d'environ dans le cas des paramètres URL, ou s'il y
a des données POST, elles arrivent par l'entrée standard du logiciel CGI qui
traite les données remises comme ça et finalement dépense le résultat déterminé
sur la sortie standard. Il est ensuite pris par le serveur web et relayé à
l'invocateur.
Ce faisant le serveur web est soulagé pour qu'il aie besoin de se saisir
exclusivement de livrer des données – des évaluations ont lieu dans des
processus entièrement autonomes.
Mais pourquoi justement CGI et pas PHP?
Contrairement à CGI il y a anguille sous roche avec PHP: Il faut utiliser une
particulière langue script, tandis qu'on n'a pas cette limitation sous CGI.
Dans le dernier cas on pourrait utiliser n'importe quel logiciel que prend des
données sur son entrée standard et fournit ses résultats en place sur sa sortie
standard s'ils sont conçus pour CGI ou sont en état de s'adapter à cette
condition. Il permet d'utiliser aussi des scripts shell, des scripts écrits à
une particulière langue script (Perl, Python, Tcl, etc.) ou bien aux logiciels
à part entières. Vous virtuellement n'avez aucunes limites.
En outre vous avez toutes options avec ce que vous retournez à l'invocateur:
Vous pouvez lui indiquer quelles données vous retournez en quelle façon!
Comment Perl entre en jeu
Perl est caractérisé par une flexibilité extraordinaire concernant la
programmation qui permet à faire presque toutes choses. Vous y pouvez assigner
des données de toutes sortes aux variables sans avoir besoin de casser sa tête
sur leur structure (sauf distinguer entre des scalaires – soit des valeurs
uniques – des listes ou des hashes), Perl va accomplir le reste. Et même s'il
faut transformer des données d'une forme à une autre, il ne faut pas y
gaspiller ni votre énergie ni votre temps, parce Perl va venir à bout d'y
faire.
En outre on peut modulariser des scripts Perl pour qu'on puisse délocaliser des
fonctions que vous voulez utiliser dans plusieurs scripts dans un additionel
fichier que vous pouvez inclure dans vos scripts. Vous y évitez noter le même
code aux plusieurs points, donc rendre la maintenance du code signifiamment
plus facile. Lorsqu'il y a des problèmes qui apparaissent, il faut seulement
modifier le code à un seul point; ces changements viennent en effet à touts
points où vous avez inclus le module affecté.
En outre le style de programmation de Perl qui est laxistement inspiré par
celui de C rend le travaile plus facile encore une fois et vous accorde des
additionelles libertés. Ça va rendre le travail plus facile encore une fois et
en lieu de vous saisir de la représentation interne des données – ainsi que des
transformations si nécessaire – vous pouvez les utiliser virtuellement à
volonté.