Chargement dynamic du contenu sur une page HTML locale

Le contexte:
Fondamentalement, je joins un petit document d’aide HTML pour accompagner mon programme (non destiné à être sur un serveur, visualisé localement). HTML simplement parce que je suis le plus à l’aise pour créer des documents mais que je souhaite également un contenu interactif / dynamic que je ne peux pas créer au format PDF ou quoi que ce soit d’autre.

Je remplace dynamicment le contenu lorsque vous cliquez sur un lien au lieu de faire en sorte que chaque page ait besoin de sa propre page HTML, ce que je fais habituellement pour pouvoir modifier le menu, la bannière et tout ‘fichier HTML sans avoir à ajuster chaque fichier HTML unique pour un changement minime dans le contenu partagé.

Méthode actuelle:
À l’heure actuelle, tout est fait via javascript et jQuery. Lorsqu’un utilisateur clique sur un lien, j’utilise la fonction load () de jQuery pour charger le contenu approprié (un fichier html) et remplace la div de contenu par le contenu du fichier html chargé. Actuellement, je n’utilise que des liens relatifs. Par exemple, la fonction principale est quelque chose comme ci-dessous:

$("#ContentBox").load("content/faq.html");

Cela a effectivement fonctionné il y a quelques semaines lorsque je l’ai écrit pour la première fois. Ce n’est pas comme si j’avais tout construit et n’avais pas testé son concept de base jusqu’à présent. Mais maintenant, il semble que tous les navigateurs le bloquent. Chrome dit:

 XMLHttpRequest cannot load file:///C:/[....]/content/home.html. Cross origin requests are only supported for protocol schemes: http, data, chrome-extension, https, chrome-extension-resource. `

Question:
Donc, je comprends pourquoi cela se produit car c’est un risque potentiel pour la sécurité de permettre cela, je veux juste trouver un bon moyen de le contourner tout en faisant ce que je veux (si cela est possible). Je veux dire que je pourrais simplement précharger tout le contenu en tant que variables de chaîne énormes dans le fichier javascript ou en tant que div cachés qui sont activés et désactivés, mais j’espérais quelque chose d’un peu plus élégant.

Et je ne peux pas m’attendre à ce que tous les utilisateurs de mon programme installent un serveur Web local uniquement pour visualiser l’aide.

J’ai examiné les classes File et FileReader, mais elles nécessitent une entrée utilisateur pour de nombreuses fonctions. Il y a aussi iFrames mais cela introduit toutes sortes de bizarreries qu’il faut prendre en compte et je déteste les iFrames.

S’il s’agit de contenu local, vous ne devriez pas le charger via ajax. Une option à votre disposition consiste à configurer vos fichiers d’aide en tant que modèles Javascript locaux. Vous pouvez ensuite vous y référer en utilisant une bibliothèque de modèles telle que moustache ou soulignement et les lier dans votre application de la manière suivante:

Si vous ne souhaitez pas utiliser une bibliothèque de modèles, vous pouvez configurer helpfile.js en tant que données JSON, mais vous devrez d'abord échapper les caractères de citation.

Si vos documents d’aide doivent uniquement être visualisés sur un ordinateur Windows, vous devez envisager d’utiliser des applications HTML pour éliminer les problèmes d’origine croisée. Vous pouvez également contourner ce problème en combinant tous les fichiers de code source dans des zones de texte masquées. Je l’ai fait lol

C’est la solution que j’ai choisie dès maintenant pour quiconque est toujours intéressé. A la fin du corps se trouvent tous les divs avec les différents contenus de page stylés comme ceci:

L’identifiant est important car il devient le nom de la page et le type de classe, que vous pouvez nommer comme vous voulez, que je masquais avec une visibility:hidden; ainsi que lui a donné un positionnement absolu à 0,0 – juste au cas où – afin qu’ils n’interagissent pas avec d’autres éléments et bousiller la mise en page.

Lors du chargement de la page, ainsi que de nombreuses autres fonctions, je stocke les éléments dans un object associatif javascript par nom de page.

 var content = {}; function onLoadThisGetsCalledSomewhere() { // loop through all of those divs $(".div-content").each( function() { // using $(this) to grab the div in the scope of the function here var element = $(this).element; var name = $(this).attr('id'); // remove it from the html (now it exists only in the content object) element.detach(); // remove that style class that makes it invisible element.removeClass('content-div'); // put it into memory content[name] = element; } ); }

Ainsi, quand un lien vers une autre page est cliqué, onclick fait quelque chose comme switchPage(pageName) , disons.

 function switchPage(requestedPage) : // somewhat simplified, real version has case and null checks that take you to 404 page var contentElement = content[requestedPage]; // replace content in some container div where you want content to go $("#TheContentContainer").empty().append( contentElement ); // have to adjust size (width possibly too but I had a fixed width) $("#TheContentContainer").height( contentElement.height() ); }

Je ne suis pas au même ordinateur, alors je rédige tout cela de nouveau, pas de copier / coller, il peut donc y avoir quelques bugs / fautes de frappe (Caveat emptor – je le réparerai demain). La version que j’ai utilisée est aussi un peu plus compliquée, car j’ai des sous-pages et des modifications de la barre de menus gérées de manière dynamic. Permet également d’ouvrir correctement les “liens” dans de nouvelles fenêtres / tabs si une telle action est effectuée. Mais ce n’est pas important ici maintenant.

Je suppose que ce n’est pas très différent avec les divs cachés (l’avantage ici est la fonction detach () pour le supprimer du html) ou le stockage de longues chaînes de code html dans java vars (beaucoup plus lisible que cela), mais je pense que c’est bien avantage est est beaucoup plus propre (IMHO) et jusqu’à présent, je l’aime bien. Le seul inconvénient est que, avec beaucoup de pages, vous obtenez un énorme document HTML qui peut être difficile à éditer, mais tout bon éditeur devrait avoir une fonctionnalité de signet pour le rendre plus facile à atteindre. à la recherche de. C’est aussi une mauvaise idée si ce n’est pas local, mais s’il est en ligne, utilisez simplement la fonction load () de jQuery.