Actualites  Archives
 Inscription | Plan du site | 5  visiteurs actifs  
  
     A la Une
  Actualités
  Dossiers
  Coin Technique
  Annonces Web
  Référencement

     Diagnostic
  Popularité Site Web
  Positionnement Moteur
  WebPage Alerte
  Positionnement Google

     Archives
  Sélection
  Expérience qui parle
  Internet quotidien
  Tous les dossiers

     Services
  Communiqués de Presse

     Contact
  Nous contacter
  La protection des données personnelles

     Technique
  Merise

     Login
   
    
Inscription

Mot de passe oublié?

     Rechercher
    
   

 Actualités > Sélection


Bien organiser pour mieux développer
Dans le développement d'applications "lourdes", c'est à dire le fabrication d'exécutable, on est très sensible à l'architecture des composants. Avec les langages de scripts, la souplesse d'écriture peut nous faire oublier certaines règles qui peuvent grandement nous faciliter la vie.

J'ai déjà abordé certains aspects permettant d'augmenter la qualité du logiciel. Je vais en aborder 'autres plus spécifiques aux langages de scripts que sont PHP et ASP.

Je vais approfondir la technique d'externalisation. Le problème auquel nous sommes actuellement confronté avec les pages HTML, dynamiques ou non, est le mélange entre du contenu, du HTML, des balises de présentation (style), du code javascript. Quand en plus la page est dynamique s'entrelace dans tout cela des balises et du code PHP ou ASP. Si l'on n'y fait pas attention, cela devient vitre inextricable.

On va donc essayer d'y mettre de l'ordre, oh! pas pour le navigateur qui s'y retrouvera toujours si tant est que toute la syntaxe soit correcte, mais bien pour nous ; pour pouvoir faire des ajouts, des modifications sans avoir à s'arracher les cheveux. Quand tout devient spaghetti, on a vite fait de ne plus s'y retrouver, d'oublier des balises de fermeture etc.. Et actuellement les logiciels ne s'y retrouvent pas non plus entre l'ouverture d'une balise en HTML et sa fermeture en script.

Première règle

Soyons cohérents, une balise ouverte en HTML doit être fernée en HTML. Ne pas faire ceci 
<bal>
<?php print "</bal>" ?>

Je prolongerai cette règle par la suivante, ne pas alterner de façon intempestive le HTML et le langage de script. Est-ce que cela joue sur les performances du serveur, je n'en sais à vrai dire rien, mis cela joue surement sur les possibilités de relecture de nous pauvres humains ;-)).

La mise en forme

En ce qui concerne la mise en forme, le style, la plupart des navigateurs utilisés supportant les feuilles de style, il faut les mettre en oeuvre. Il est plus facile de modifier un style largement utilisé par une feuille de style, mais cela fait aussi moins de caractères qui traînent dans le HTML et cela perturbe donc moins la lecture du source de la page. Insérer les styles dans la page elle-même ou utiliser une feuille de style externe, c'est à chacun de voir.

Javascript

Je suis partisan de ne pas disséminer le code javascript dans le HTML et dès que j'ai plus de deux fonctions à appeler sur un évènement je les regroupe dans une fonction que j'appelle à leur place. La plupart du temps je sors le javascript en librairie externe aussi, afin de n'avoir qu'un lien dans le HTML.

Langage de script

Pour le PHP et l'ASP, je propose plusieurs règles simples. J'ai déjà énoncé la première dans un article précédent et plus haut dans l'article. A savoir ne pas alterner trop fréquemment le HTML et le script. Quand on doit écrire des valeurs provenant d'une base de données, il vaut mieux écrire le HTML par le langage que de fermer le script, mettre du HTMl, ouvrir le script etc... Le problème est qu'effectivement les outils ne savent pas trouver les balises HTML dans les chaînes de caractères des scripts. Ils peuvent donc trouver des incohérences dans le HTML

Il est sain aussi de sortir un maximum de traitements dans des include que l'on spécialise. En les spécialisant on a vite fait de retrouver des parties de codes réutilisables, pour peu qu'on les ait rendus indépendants du fonctionnel et que les interfaces soient clairement décrits et explicités.

Conclusion

Ce que j'ai écrit là ne correspond pas à une recherche d'optimisation des temps de traitement des pages web. Certains diront peut-être même au contraire. Mais le surcoût est négligeable, et de toute façon sans comparaison avec la maintenabilité de nos pages web. Depuis le début l'informatique a été un compromis entre l'espace et le temps. Ici, c'est sur notre temps à nous que nous gagnons quitte à en faire perdre un peu aux machines.

Bonne lecture, à bientôt sur le forum ou par messagerie.

Daniel Lucazeau
Ajornet.com
Chef de projet Internet
Développeur informatique

 Imprimer Donner votre avis

 
 

Sam-Mag - Un site du réseau ACORUS 1996-2007
© Copyright ACORUS All rights reserved.- Mentions légales

Ce site respecte la loi Informatique et Libertés. Pour en savoir plus sur la protection des données personnelles, cliquez

 
Webmaster