Tous les weblogs de ce site aggrégés.

Pages: << 1 ... 128 129 130 131 132 133 134 135 136 137 138 >>

01.01.96

Questions HTML

  20:52:00, par fplanque   , Catégories: HTML & CSS

Voici quelques questions fréquemment posées à propos de HTML:

Pourquoi ne peut-on pas formater un texte sous HTML avec la même richesse de fonctions que dans un traitement de textes? (Par exemple la justification à doite et à gauche, les tabulations...)

Il faut bien comprendre l'objectif de HTML, à savoir structurer l'information. HTML n'est pas un langage de présentation ou de description de page (comme PostScript). HTML n'est pas une application WYSIWYG! Il n'est pas fait pour garantir que ce que vous voyez sur votre écran lorsque vous écrivez votre texte sera ce qui sera vu sur l'écran d'un utilisateur lorsqu'il lira ce texte.

Néanmoins, les diverses extensions à HTML et même HTML 3 permettent de donner des indications de plus en plus précises sur la manière dont un texte, paragraphe, phrase ou mot doit être affiché sur l'écran de l'utilisateur. Certes, il ne s'agit là que d'indications, mais on peut prévoir que ce genre de fonctionnalités va se généraliser dans un futur proche...

D'un autre côté, on observe le succès grandissant de formats de fichiers tel que Adobe Acrobat (.PDF) permettant de stocker sous une forme compacte un document multimédia et sa mise en page précise.


Comment peut-on placer des boutons et des animations sur une page HTML? (Comme avec un logiciel multimédia...)

Il faut bien comprendre l'objectif de HTML, à savoir structurer l'information. HTML n'a pas été inventé pour réaliser des applications multimédia interactives et pilotables à la souris.

Néanmoins, les souhaits des utilisateurs allant dans ce sens, HTML est en passe de se voir dôté d'extensions ou plutôt de collègues permettant d'assurer des fonctions plus multimédia. On note en particulier:

  • Java. Un langage permettant d'intégrer des objets intelligents dans les pages HTML. Java ouvre la voie aux animations, aux jeux, et toute sorte d'application où le traitement s'effectue du côté client plutôt que par requêtes au serveur.
  • VRML. Virtual Reality Modeling Language. Il permet de décrire un scène en trois dimensions. Cette scène peut être transférée sur le Web comme le serait une image, mais elle serait ensuite affichée par le logiciel client et l'utilisateur pourrait alors se promener à l'intérieur de cette scène.

Qu'est ce que HTML 3?

HTML 3 est actuellement à l'étude pour succéder à l'actuel HTML 2. Néanmoins, très peu de browsers implémentent pleinement le HTML 3 à ce jour (l'un des rares étant Athena).

La lenteur d'évolution de la norme à conduit des acteurs tels que Netscape ou Microsoft à implémenter leurs propres extensions à HTML 2 dans leurs browsers respectifs.

Les améliorations proposées par HTML 3 sont les suivantes:

  • Tableaux
  • Texte s'arrangeant autour des illustrations
  • Notations mathématiques
  • Listes personnalisées
  • Tabulations horizontales
  • Bandeau de navigation fixe
  • Style Sheets

A part la présence de nouveaux marqueurs, les fichiers HTML3 peuvent être identifiés grâce aux caractéristiques suivantes:

  • MIME content type: text/html; version=3.0
  • Extensions de fichiers: .html3 ou .ht3 sous DOS.

Editeurs HTML

  20:51:00, par fplanque   , Catégories: Développement Web

Même lorsque l'on connaît parfaitement les différents marqueurs HTML, il devient rapidement fastidieux de taper de longues pages "à mains nues"... surtout si vous devez le faire toute la journée.

Pour vous simplifier la tâche, il existe divers outils logiciels vous permettant de créer plus facilement vos pages HTML. Ces outils remplissent une ou plusieurs des fonctions suivantes:

  • Conversion d'un fichier issu d'un traitement de texte (.DOC.RTF, etc.) en fichier HTML.
  • Insertion des tags HTML par simple clic sur un bouton ou par raccourci clavier.
  • Insertion aisée de caractères accentués ou caractères spéciaux, conversion automatique.
  • Insertion d'images et liens vers tous types de fichiers au moyen d'un sélecteur de fichiers.
  • Vérification de la syntaxe.
  • D'autres petits gadgets qui simplifient la vie...

Vous choisirez vos outils en fonction de vos préférences, mais aussi en fonction de la machine sur laquelle vous travaillez.

N'oubliez pas que vous pouvez très bien éditer vos pages HTML sur un PC ou un Macintosh et ne les transférer sur le serveur HTTP (sous UNIX par exemple) que lorsqu'elles sont terminées.

Cette méthode présente néanmoins certains inconvénients. L'un d'eux est le fait que beaucoup d'éditeurs sur PC utilisent encore exclusivement les noms de fichier au format 8.3. Par conséquents ils génèrent souvent des références vers des fichiers portant l'extension .htm alors que sur la machine serveur, les fichiers doivent impérativement porter l'extension .html. Dans ce cas, il faudra ajouter des 'l' à la main aux endroits concernés...

HTML: Imagemaps

  20:48:00, par fplanque   , Catégories: HTML & CSS

Qu'est-ce que c'est exactement?

Un Imagemap est une image incluse dans une page HTML qui, lorsque vous cliquez dessus, vous renvoie vers une autre URL. Jusque là, rien de bien étonnant... si ce n'est le fait que l'URL sur laquelle vous allez être renvoyé dépend de l'endroit précis de l'Imagemap sur lequel vous avez cliqué.

Voici une petite démonstration dans laquelle vous serez renvoyé vers une page HTML différente selon que vous cliquiez sur le rectangle, le cercle ou le fond de l'image:

 

  (cet exemple ne peut pas fonctionner sur ce serveur, désolé.)

Bien sûr, cet exemple n'est pas d'une grande utilité en soi. Quelques applications pratiques de l'Imagemap sont:

  • Barre d'icônes permettant d'accéder à différentes fonctions
  • Plan de bâtiment permettant d'accéder aux différents salles
  • Photo permettant d'obtenir des informations sur tel ou tel détail

Comment ca marche?

Il existe plusieurs méthodes pour gérer un Imagemap:

  • Lorsque vous cliquez sur l'image, le client envoie les coordonnées exactes (en pixels) de l'endroit sur lequel vous avez cliqué à un petit programme CGI (exécuté sur le serveur) qui se charge ensuite de vous rediriger vers l'URL associée à la zone dans laquelle vous avez cliqué.

    Cette méthode fonctionne avec la quasi totalité des serveurs HTTP et il vous suffit de disposer de l'utilitaire imagemap dans le dossier cgi-bin

  • Les serveurs HTTP les plus récents tels que NCSA HTTPd version 1.5 intègrent directement la gestion des Imagemap et il n'est plus nécessaire de passer par un quelconque module CGI.

    Cette méthode est beaucoup plus efficace que la précédente et nous vous recommandons vivement de l'utiliser si votre serveur la supporte.

  • Les clients les plus récents tels que Netscape Navigator 2 offrent la possibilité de gérer ce que l'on appelle des Client-Side Imagemaps. Dans ce cas, c'est le client qui s'occupe de déterminer dans quelle zone vous avez cliqué et qui fait directement la requête vers l'URL correspondante.

    C'est de loin la méthode la plus efficace en termes de performances. Ceci dit, très peu d'utilisateurs disposent à ce jour d'un client compatible avec cette méthode!

ATTENTION: Dans ce qui suit, nous expliquons comment mettre en oeuvre la première méthode (universelle): utilisation d'un script CGI.


Méthode à suivre

1-Installation du module CGI imagemap

Le module CGI imagemap est généralement fourni avec votre serveur HTTP. Il doit se trouver dans le répertoire cgi-bin.

Si le répertoire cgi-bin de votre serveur ne contient pas ce module, vous avez deux solutions:

  • Si vous avez accès en écriture au répertoire cgi-bin, vous pouvez vous procurer le module et l'installer vous même.
  • Sinon, demandez à l'administrateur de votre serveur de s'en charger...

2-Créer l'Imagemap

Votre Imagemap sera en fait constitué de deux parties:

  • L'image en elle même, telle qu'elle apparaîtra à l'écran. Elle doit être au format GIF.
  • Le fichier décrivant les différentes régions de l'image et leur URL associée. Il s'agit d'un fichier texte auquel on donnera en général l'extension .MAP.

L'image GIF sera créée avec vos outils de dessin favoris. Quant au fichier .MAP, vous pourrez soit utiliser un utilitaire adapté tel que mapedit , soit l'écrire à la main...

ATTENTION: Dans ce qui suit, nous expliquons la syntaxe de .MAP de NCSA, par opposition à la syntaxe CERN.

Le fichier .MAP utilisé pour l'exemple donné plus haut est le suivant:

default /~fplanque/Publier/imapdef.html
#rectangle
rect    /~fplanque/Publier/imapbox.html 11,12 52,47 
#cercle
circle  /~fplanque/Publier/imapcir.html 73,68 81,91 

Les lignes commençant par un # sont des commentaires. Les autres lignes définissent des zones. Chaque ligne consiste en une indication de la forme de la zone, suivie de l'URL associée, suivie d'un certain nombre de coordonnées x,y en pixels, relatives au coin supérieur gauche de l'image et définissant la zone en question.

Les différentes formes disponibles sont les suivantes:

default
Définit l'URL par défaut. 
Coordonnées: aucune
rect
Définit un rectangle. 
Coordonnées: haut-gauche bas-droit
circle
Définit un cercle (un disque pour être précis). 
Coordonnées: centre un_point_du_périmetre
poly
Définit un polygone de 100 sommets au plus. 
Coordonnées: coordonnées de tous les sommets
point
Définit un point, l'URL retenu sera alors celle du point le plus proche de l'endroit ou l'utilisateur a clique. 
Coordonnées: le_point

3-Intégrer l'Imagemap dans une page HTML

L'Imagemap de l'exemple donné plus haut a été inclus dans cette page HTML de la manière suivante:

<A HREF="http://www.dom.org/cgi-bin/imagemap/~fplanque/Publier/imap.map">
  <IMG SRC="imap.gif" ISMAP>
</A>

Vous devez donc commencer par intégrer l'image GIF dans votre page HTML au moyen du marqueur IMG. Notez la présence de l'attribut ISMAP. C'est grâce à la présence de cet attribut que le client saura qu'il faut envoyer les coordonnées précises du point de l'image sur lequel on a cliqué.

Vous devez ensuite inclure cette image dans un lien au moyen du marqueur <A>. Vous ferez référence au module CGI qui traite les imagemaps (ici http://www.dom.org/cgi-bin/imagemap) et vous ajouterez derrière le chemin d'accès au fichier .MAP (ici /~fplanque/Publier/imap.map). Ce chemin d'accès (extra PATH_INFO) sera transmis au module CGI imagemap qui saura ainsi où trouver le fichier .MAP.


Autres sources d'informations

  • mapedit, un petit utilitaire permettant de générer graphiquement les fichiers .MAP (existe sur différentes plates-formes).

Compteurs d'accès Web

  20:45:00, par fplanque   , Catégories: Développement Web

L'installation d'un compteur d'accès sur votre site web vous permet d'avoir un retour d'informations sur le nombre de personnes qui consultent effectivement votre site. La présence d'un compteur permet également aux lecteurs d'en connaître la popularité...

Il existe deux méthodes pour compter les accès:

  • Examiner le fichier de log de votre serveur http.
  • Intégrer un appel à un programme CGI depuis l'une de vos pages.

Simple et efficace

Nous allons ici nous intéresser uniquement à la deuxième méthode, qui consiste à appeler un programme CGI "compteur" depuis une page HTML. Le principe en est le suivant: à chaque fois qu'un client charge la page HTML en question, il y trouve une image intégrée à l'aide du marqueur <IMG>. Il demande donc le chargement de cette image. Or il se trouve que cette image fait en fait référence à un programme CGI. Ledit programme CGI consulte son fichier compteur, l'incrémente de 1 puis produit en temps réel une petite image représentant les chiffres d'un compteur...

Certains compteurs permettent aussi de ne pas afficher de compteur et se contentent alors d'enregistrer les accès dans un fichier. Pour ne pas afficher le compteur, le programme va en fait afficher une image GIF transparente de 1 pixel sur 1 pixel!

Inconvénients

Un tel compteur d'accès présente néanmoins quelques limitations:

  • A chaque fois qu'une même personne se reconnecte sur un site, le compteur est incrémenté. Le compteur ne compte donc pas les personnes mais les accès à la page.
  • Le compteur est également incrémenté si un lecteur appuye sur le bouton reload de son browser.
  • Le compteur n'est pas toujours incrémenté si la page est dans le cache local du client.
  • Le compteur n'est jamais incrémenté si un lecteur référence directement une page précise d'un site Web, sans passer par la page de garde (en admettant que seule la page de garde comporte un compteur!) Le compteur ne compte donc pas les accès au service mais à la page de garde su service.

Un certain nombre de ces inconvénients pourraient être contournés avec un compteur s'appuyant sur les fichiers de log du serveur httpd, mais cela se fait au prix d'une plus grande complexité. Nous ne relèverons pas ce défi là ici.


Odometer

Odometer est un compteur très simple écrit en C sous UNIX.

Il est peut être appelé très simplement de la manière suivante:

<IMG SRC="http://www.planete.net/cgi-bin/odometer?test>

Voici le code source en C pour UNIX: odometer.c.

Common Gateway Interface (CGI)

  20:41:00, par fplanque   , Catégories: Développement Web

Introduction

La Common Gateway Interface (CGI) est une norme définissant l'interfaçage d'applications externes avec des serveurs d'information (dans le cas qui nous intéresse: des serveurs HTTP).

La motivation qui vous conduira à utiliser CGI pour faire appel à des programmes externes est la suivante: lorsqu'un document HTML est envoyé sur le Web, il s'agit d'un document statique, un fichier texte dont l'information ne change pas tant que vous n'avez pas édité ledit fichier. Il existe néanmoins un grand nombre de cas où vous aimeriez envoyer de l'information dynamique, voire changeante d'un instant à l'autre. Un programme externe appelé par CGI ("programme CGI") permet d'arriver à ce résultat dans la mesure où ce programme est exécuté en temps réel, au moment où le client fait une requête au serveur HTTP.

Imaginez par exemple que vous vouliez connecter votre base de données sous UNIX au World Wide Web de manière à ce que les gens du monde entier puissent l'interroger en temps réel. Pour ce faire, vous pouvez créer un programme CGI que le serveur HTTP invoquera pour transmettre des critères de recherche au moteur de votre base de données et recevoir les résultats de la recherche qu'il transmettra alors au client pour affichage. Ceci est un exemple typique de passerelle - gateway en anglais - d'où le nom de Common Gateway Interface.

Cet exemple de base de données est une idée relativement simple mais néanmoins assez délicate à implémenter dans les faits. Il existe en fait un grand nombre d'applications beaucoup plus simples de CGI, par exemple: inclure l'heure courante dans un document HTML. Mais il n'y a pratiquement aucune limite à ce que vous pouvez faire avec un programme CGI. Rappellez vous simplement que votre programme est exécuté en direct et ce que vous y faites ne doit donc pas prendre trop de temps, faute de quoi l'utilisateur ne ferait rien d'autre que d'attendre devant un écran vide que votre programme veuille bien envoyer de l'information.

 


Spécification

Etant donné qu'un programme CGI est un exécutable, son utilisation correspond quasiment à laisser n'importe qui dans le monde e xécuter un programme sur votre ordinateur... ce qui n'est pas précisément la chose la plus sûre à faire (piratage, malveillance, virus...). Cela induit la nécessité de prendre quelques précautions au niveau de la sécurité.

L'une des précautions qui affectera le plus la plupart des utilisateurs est le fait que tous les programmes CGI devront généralement être placés dans un repértoire spécifique de l'arborescence, généralement nommé cgi-bin. Lorsque le serveur reçoit alors une requête sur une URL du type http://www.dom.org/cgi-bin/prog.html il saura qu'il doit exécuter le programme nomméprog.html plutôt que de l'envoyer tel quel vers le client comme on aurait pu s'y attendre à la vue de l'extension .html. En effet, tout fichier se trouvant dans le répertoire cgi-bin sera considéré par le serveur HTTP comme étant un exécutable.

D'autre part, le répertoire cgi-bin est généralement contrôlé par l'administrateur du serveur. Cela a deux conséquences:

  • N'importe qui ne peut pas créer un programme CGI et l'administrateur du serveur peut vérifier leur sécurité avant de les rendre accessible au public.
  • Le serveur HTTP n'exécutera que les programmes se trouvant dans ledit répertoire ou l'un de ses sous-répertoires et n'exécutera jamais un programme placé ailleurs sur vos disques. Cela empêchera un individu malveillant d'éxécuter n'importe lequel des programmes figurant sur votre ordinateur depuis l'autre bout de la planète. Cela empêchera également n'importe quel utilisateur (par exemple vous!) autorisé à placer des pages HTML sur un serveur d'y placer également des programmes CGI sans visa de l'administrateur.

Il existe d'autres moyens de faire éxécuter un programme CGI par votre serveur HTTP, mais seul l'administrateur du serveur peut les mettre en place. Un administrateur particulièrement laxiste laissera par exemple son serveur exécuter n'importe quel fichier possèdant l'extension .cgi.

En pratique, les utilisateurs peuvent souvent placer librement des documents statiques (pages HTML, images, etc.) sur le serveur Web de leur organisation en les copiant dans un répertoire spécial. Par contre, ils ne peuvent généralement pas rendre leurs programmes accessibles par le Web en utilisant CGI parce qu'ils n'ont pas la permission de les copier dans le répertoire cgi-bin.

Dans la majorité des cas, vous devrez donc vous adresser à l'administrateur de votre serveur WWW pour installer un programme CGI... à moins que vous ne soyez administrateur de serveur vous même!

Un programme CGI peut être écrit dans la plupart des langages disponibles sur vot re système. Les seules conditions sont que le langage en question vous donne accès aux variables d'environnement et qu'il permette d'écrire sur la sortie standard. Parmi les langages que vous pouvez utiliser vous trouverez:

  • C et C++
  • Fortran
  • Perl
  • TCL
  • sh, csh, ksh ou n'importe quel autre shell UNIX
  • Visual Basic (sous Windows)
  • AppleScript (sur Macintosh)

Si vous utilisez un langage de programmation tel que C, C++ ou Fortran, vous savez que vous devez compiler vos programmes avant de pouvoir les exécuter. Par contre, si vous utilisez un langage de script tel que Perl, TCL ou un shell UNIX, vous pouvez directement exécuter le fichier source (pour être précis, on doit dire que le fichier source sera interprété).

Attention: Dans tous les cas, vérifiez que le fichier à exécuter possède bien une permission d'exécution, en particulier si vous êtes sous UNIX.

Beaucoup de personnes préfèrent écrire leurs programmes CGI sous forme de scripts plutôt que sous forme de programmes compilés. En effet, sous forme de scripts, ils sont plus faciles à débugguer, à modifier et à maintenir. Un autre avantage du script est que l'administrateur du serveur peut vérifier facilement que ledit script n'ouvre pas de brèche dans la sécurité du système. Un script interprété induit néanmoins une sérieuse dégradation de performances par rapport à un programme compilé. 


Exemples

Voici deux exemples relativement simples de scripts CGI.

  • Date courante est un script CGI extrêmement simple qui produit un document HTML contenant la date et l'heure courantes. 
    Le code source est écrit en sh
  • Interface finger est un script CGI un peu plus compliqué qui prend un paramètre en entrée. Si aucun paramètre n'est fourni, le script affiche un champ ISINDEX pour que l'utilisateur saisisse un nom. Une fois que ce nom est saisi, le script s'appelle lui même à nouveau, mais cette fois, le nom saisi est transmis en argument. Dans ce cas, c'est à dire lorsque le script est appelé avec un argument, il appelle la commande UNIX finger et intègre le résultat de cette commande dans la document HTML qu'il produit. 
    Le code source est écrit en sh.

Pages: << 1 ... 128 129 130 131 132 133 134 135 136 137 138 >>