18041 sujets

Questions générales et questions de débutants

Comment générer une page HTML

Bonjour à tous et bonne année nouvelle.

L'objet de mes cogitations actuelles est "comment générer une page HTML"?

En gros il y a 3 façon d'obtenir une page HTML
- la première et la plus évidente est d'écrire du code HTML en utilisant un éditeur de texte approprié
- la deuxième est de faire générer du code HTML par le serveur
- la troisième est de faire générer du code par Javascript

Pour une page contenant du texte, des images et des liens vers d'autres pages, la première méthode est bien entendu la plus appropriée. L'évolution du CSS a permis de réaliser pas mal de choses sans faire appel au Javascript.

Par contre pour une page contenant des informations variables provenant d'une base de données, une fois définie la structure de base de la page "à la main", on a le choix entre
A) faire générer le code HTML par le serveur à partir des données de la base de données
B) utiliser le serveur pour extraire les données et les mettre sous forme d'un "objet" JSON, puis faire générer le code final en Javascript

Pendant longtemps, j'ai utilisé la méthode A, avec pour résultat le développement d'objets PHP disposant d'une méthode "toHTML()" générant le code approprié.

Maintenant je me demande dans quelle mesure l'utilisation de la méthode B ne serait pas préférable, pour les raisons suivantes:
- nous avons besoin de faire face à des écrans de taille très diverses, et il n'est pas toujours très simple de concevoir un code HTML qui soit complètement responsive par l'utilisation de mediaqueries. J'ai été ainsi conduit récemment à faire en sorte que le code généré soit double: une partie pour grands écrans, une partie pour petits écrans, le choix de la partie qui s'affiche étant déterminé par mediaqueries
- qui dit petite taille d'écran dit affichage de peu d'information à la fois, et donc utilisation de mécanismes permettant d'afficher dynamiquement des informations complémentaires.
Cela conduit à l'utilisation d'AJAX, et donc de mécanismes Javascript pour mettre en page les informations complémentaires.

Par ailleurs, même si à mon avis ce n'est pas un problème extrêmement important, recevoir des données en JSON, et de plus par petites quantités, réduit le débit nécessaire. Les mettre en forme en Javascript n'est pas un problème compte tenu de la rapidité des CPUs actuels.

Pour la programmation, c'est en gros similaire, et je trouve même à l'expérience légèrement plus facile de gérer le DOM en Javascript que générer du HTML en PHP, une fois définis les bons outils.

En tant que français, adepte du "juste milieu", on peut penser qu'il doit exister une voie intermédiaire. Si elle existe elle n'est pas simple à définir, car par expérience je constate que générer du HTML par PHP et le compléter par Javascript ne fait que compliquer les choses.

J'aimerais avoir vos opinions sur ce sujet.
Je ne trancherais pas le problème mais une chose est sûre pour moi : je ne sortirais pas l'artillerie lourde juste pour obtenir un affichage html différent selon la taille de l'ecran. Par contre, pour ajouter un aspect dynamique au site, alors oui.

PS : bonne année !
Modifié par Olivier C (01 Jan 2019 - 14:44)
Bonjour PapyJP,

De nos jours il est possible de se passer totalement du PHP et d'utiliser uniquement du JS à la fois pour générer des pages, mais aussi pour les interactions et autres stockages en base de données.

Je vous recommande de regarder du coté de node.js et ses amis/concurrents.

Bonne journée et bonne année !
Modérateur
Bonjour,

Si la question est de n'utiliser qu'un seul langage, comme besky, je pense que node.js est une solution (c'est du javascript mais du côté du serveur, à la place du php).

Si la question est de vouloir générer la page en javascript côté client, je suis dubitatif. Déjà, ça risque d'être plus lent. Ensuite, si par exemple on utilise beaucoup AJAX pour aller piocher dans une base de données, il faudra quand même coder quelque chose côté serveur. Et surtout, ça perturbe pas mal les moteurs de recherche (même si y en a qui vont dire qu'ils font des progrès pour s'en sortir quand même).

Amicalement,
Salut Papy,

C'est plus une question d'architecture au final (tu cites l'utilisation du PHP côté serveur mais ça aurait pu être en Java ou en Python si tu le voulais). Elles sont complètement différentes dans les deux exemples et leur intérêt va bien au delà d'un problème de responsive design. À ce propos, je crois même que le responsive design n'a strictement rien à voir avec la manière dont tu récupères les données. C'est juste un problème d'intégration HTML / CSS.

Ton premier exemple c'est l'architecture old school qui a été utilisée pendant très longtemps : le traitement des données et la génération de la page HTML se fait entièrement côté serveur. L'avantage c'est que la session utilisateur est gérée aussi par le serveur, donc c'est facile de sécuriser l'accès aux données. Le défaut c'est que lorsque qu'on souhaite faire une refonte graphique, bah c'est un peu tout le code qui doit être manipulé.

Le second exemple c'est l'architecture à la mode depuis l'arrivée des frameworks comme Angular. On a deux implémentations complètement indépendantes. Un client qui gère l'affichage des données récupérées par le biais de requêtes vers un serveur sous la forme d'une API REST. L'avantage c'est qu'une refonte graphique ne nécessite aucune intervention côté serveur, seul le client doit être remanié. De plus, le serveur peu exposer une partie de son API au publique en cas de besoin (comme le font beaucoup de compagnies pour permettre aux développeur de créer des plugins, mods, etc). L'inconvénient, c'est que développer une API REST (même avec les frameworks) entièrement sécurisée c'est pas hyper trivial la première fois. Car oui, le serveur ne gère plus la session utilisateur et chaque requête doit contenir un token qui permet d'authentifier et autoriser l'utilisateur.

La question qui reste actuellement, c'est quoi utiliser ? Et comment ? Là ça dépends vraiment des besoins, des compétences et des affinités avec les langages / frameworks. Dans tous les cas, je t'invite à te documenter si quelque chose te paraît obscur.
Merci de vos réponses
Quelques réponses de ma part
Olivier C a écrit :
je ne sortirais pas l'artillerie lourde juste pour obtenir un affichage html différent selon la taille de l'ecran. Par contre, pour ajouter un aspect dynamique au site, alors oui.

Je ne considère pas qu'utiliser Javascript soit de l'artillerie lourde. Dans les premiers temps de mes développements Web, je devais travailler sur le site de mon entreprise où je n'avais pas accès au serveur. Je faisais donc tout en Javascript, et j'ai fait de même quand j'ai créé le site de mon association musicale, je n'avais pas le temps d'apprendre une nouvelle techno.

La plupart des pages de ce site contiennent des listes d'éléments, essentiellement
- la liste des évènements (répétitions, concerts et autres)
- la liste des œuvres au programme des répétitions et des concerts
- la liste des membres du chœur classées par pupitre
Même avec un écran large, je suis amené à introduire beaucoup de dynamisme, par exemple:
La description d'un évènement contient :
- la date
- la nature de l'évènement
- le lieu où il se tient
- le programme de travail de cet évènement
Je ne peux pas entrer toutes ces informations dans une entrée de la table, et par conséquent :
- un clic sur le lieu de l'évènement ouvre une zone avec le plan Googlemap correspondant
- un clic sur le mot "programme" affiche la liste des œuvres au programme
- un clic sur l’œuvre ouvre affiche la liste des fichiers de travail disponibles pour cette œuvre
- un clic sur un fichier de travail affiche le fichier en question
Toutes ces informations sont disponible ou non selon que l'utilisateur s'est connecté à la partie publique ou à la partie privée du site.
Sur écran étroit, même la simple table qui ne contient que les 4 éléments de base ne tient pas dans la largeur de l'écran, et les liens sont trop rapprochés pour être facilement utilisables par "touch".

besky a écrit :
Je vous recommande de regarder du coté de node.js et ses amis/concurrents.

Franchement utiliser un produit nouveau pour moi ne m'enchante guère. De plus je crois comprendre que cela nécessite une installation d'un produit sur le serveur, ce que je ne suis pas en mesure de faire sur un site en hébergement mutualisé.

parsimonhi a écrit :

Si la question est de vouloir générer la page en javascript côté client, je suis dubitatif. Déjà, ça risque d'être plus lent.

Au contraire: un PC moderne possède une puissance énorme. On constate du reste que des produits comme Googlemap sont entièrement écrits en Javascript et que cela ne semble pas avoir énormément d'impact sur les performances.

parsimonhi a écrit :
Ensuite, si par exemple on utilise beaucoup AJAX pour aller piocher dans une base de données, il faudra quand même coder quelque chose côté serveur.

Ce code PHP existe déjà. Il génère du code HTML, il est très facile de lui faire générer du JSON.
parsimonhi a écrit :
Et surtout, ça perturbe pas mal les moteurs de recherche (même si y en a qui vont dire qu'ils font des progrès pour s'en sortir quand même).

Le site d'une association n'a pas grand chose à faire du référencement sur les pages en question. Le référencement se fait sur les pages de texte, qui, elles sont en HTML pur écrit à la main.
Ce n'est pas aux objets d'embarquer leur méthode "To HTML()", l'objet n'est que la représentation de la donnée (ou d'un concept), il doit à la rigueur avoir des représentations To XML() ou toJSON() etc. puis (vulgairement) être envoyé à un template qui fait la mise en forme HTML finale.
Faire autrement ça oblige à faire du one shoot alors qu'un moteur de templating permet de cloisonner ses éléments et de les réutiliser et surtout de faire des templates qui viennent eux mêmes surcharger un élément existant (récursivité).

Ensuite concernant les appels ajax pour générer ses zones je l'ai fais sur un projet mes retours sont que :

1. à utiliser avec parcimonie tu as vite fait de DDOS un serveur (si mutualisé).

2. niveau sécurité tu as intérêt à savoir ce que tu fais, sinon tu va vite exposer des données.

3. les boutons arrière avant et rafraichir perde leur intérêt (perturbe BEAUCOUP les internautes).

4. complexification du site js + php énorme pour finalement pas grand chose.

5. vos mieux charger la page de manière classique synchrone, et dans des cas spécifiques (principalement gestion back office d'utiliser cette façon de faire).

6. Risque que ça ne soit pas supporté par certains mobiles.

7. Rend le site HS si l'internaute utilise noscript (par sécurité par exemple).
Modifié par gray_magic (22 Jan 2019 - 16:28)
Merci de ta réponse.

Sauf à écrire à la main le HTML à chaque modification des données, je ne vois pas comment on pourrait se passer à l'a fois de fonctions de génération de HTML sur le serveur en PHP ou de génération de HTML/manipulation du DOM en JS côté client.
Comme ce site aura 20 ans l'été prochain, je n'ai pas attendu que des fournisseurs développent des "moteurs de template", j'ai fait cela moi même et ça marche plutôt bien depuis une dizaine d'années.
Auparavant, le code des parties variables était généré en JS, et ça marchait pas mal non plus.
En ce moment j'ai plutôt tendance à travailler de la façon suivante:
- gestion des données sur le site, sous la forme d'objets PHP
- export en JSON ou XML selon les cas
- génération côté client par JS
Que ça ne marche pas pour les gens qui ne veulent pas de JS ne me gène pas, ce site est essentiellement un site associatif, les visiteurs externes sont peu nombreux.
Si quelqu'un s'amuse à surcharger le serveur, grand bien lui fasse, ça mettra le site hors service pendant quelques heures, ce n'est pas très important.
Sujet clos
Aller à