Commentaires sur : Du code dans vos pages web !

Par : Ajax Syntax Highlighter 1.0 beta 1 released - Lapin Blanc : le weblog de Kévin Dunglas

Wed, 10 Sep 2008 07:48:36 +0000

[...] it’s the first public release of the new syntax highlighter announced in my previous post [...]

Par : Anonyme

Anonyme — Thu, 04 Sep 2008 07:03:14 +0000

Publier du code source dans vos pages web…

HTML et XHTML disposent de balises ddies l’affichage de code source et de dialogues homme – machine qui sont malheureusement trop souvent ignores alors quelles ont une forte valeur smantique. Elles sont vieilles comme le web et supportes par tous les…

Par : www.fuzz.fr

www.fuzz.fr — Wed, 03 Sep 2008 20:26:07 +0000

De la meilleure manière d’intégrer du code source dans les pages web…

HTML et XHTML disposent de balises dédiées à l’affichage de code source et de dialogues homme – machine qui sont malheureusement trop souvent ignorées alors qu’elles ont une forte valeur sémantique. Elles sont vieilles comme le web et supporté…

Par : Laurentj

Laurentj — Wed, 03 Sep 2008 11:36:19 +0000

ok, merci de la réponse, même si je ne suis pas pleinement convaincu

Par : keyes

keyes — Wed, 03 Sep 2008 10:58:18 +0000

Alors effectivement, la solution n’est pas parfaite. Selon moi ses principaux avantages sont :
* Profite de la performance et de l’exhaustivité (nombre de langages supportés) des solutions côté serveur. Je cite GeSHi mais on peut tout à fait utiliser Pygments ou n’importe quel autre highlighter côté serveur avec ma solution.
* S’exécute côté client ce qui à l’avantage de ne pas polluer le code pour les agents logiciels intéressés à parser le code.
* Respecte les standards et conventions que je présente dans cet article.
* Peut tout à fait être inclus dans de simples pages HTML statiques (style readme, faq, …). En cas d’utilisation hors-ligne il n’y aura simplement pas de coloration syntaxique.
* Permet d’avoir quelques fonctionnalités à la SyntaxHighlighter comme changer à la volée de mode coloré / plain text

Question ralentissement, effectivement il peut y avoir un léger temps de latence du à la requête HTTP, pas forcément plus gros que celui des solutions full JavaScript qui en plus ont tendances à bloquer toute la page.
Par contre contrairement à ce que tu avances, quelque soit le nombre de snippets dans la page il n’y a qu’une seule requête d’effectuée. Le script récupère l’ensemble des codes et l’envoi (sérialisé en JSON afin de réduire au maximum le traffic réseau).

Pour la charge du serveur, si elle devient trop importante on pourrait assez simplement mettre en place un mécanisme de mise en cache du code coloré.

Après effectivement, une solution vraiment efficace côté serveur et respectant les standards ne serait pas un mal, mais ça me prendrait plus de temps à développer que mon petit script.

Par : Laurentj

Laurentj — Wed, 03 Sep 2008 08:00:18 +0000

>GeSHi est l’un des plus populaires et performant.

populaire c’est certain. Par contre performant, c’est assez discutable.. Et le parsing est souvent perfectible (sans parler du code dégeulasse qu’il génère, même si ça s’est arrangé récement)

Conçernant Ajax Syntax Highlighter, je ne vois vraiment pas trop son intérêt par rapport à une solution full client, ou full serveur. Car là tu combines tout les inconvénients de chacune des deux solutions : ça ne s’exécutera pas coté client si le javascript est désactivé, et il peut y avoir ce temps de latence après affichage de la page, pendant lequel la colorisation se fait (même défaut que la solution full client), ce qui, à cause des requêtes http à faire, sera d’autant plus visible, surtout si la connectivité n’est pas top, et ça ralentira quand même le serveur puisqu’il doit prendre en charge le parsing (même défaut que la solution full serveur). Et ça va d’autant plus ralentir le serveur qu’il va y avoir autant de requête http en plus qu’il y a de bloc de code source à coloriser.

Bref, quels sont les réèls avantages de Ajax Syntax Highlighter par rapport aux deux autres solutions ?