2009-10-31 4 views
0

Je rencontre des problèmes pour trouver l'architecture de "chargement de page" d'un site Web.XML, XSLT et JavaScript

L'idée de base est, que j'utiliserais XSLT pour le présenter mais au lieu de le faire de la manière classique avec les balises XSL je le ferais avec JavaScript. Chaque lien devrait donc se référer à une fonction JavaScript qui modifierait le contenu et les menus de la page. La raison pour laquelle je veux le faire de cette façon est de permettre à JavaScript d'afficher dynamiquement chaque page en utilisant les données fournies dans le premier fichier XML initial au lieu de faire une demande de serveur "complète" pour la page spécifique , qui a simplement trop d'inconvénients. Le problème de base est que, après avoir cherché sur le web une solution pour accéder au XML "sous-jacent" du document avec JavaScript, je ne trouve que des solutions pour accéder aux fichiers XML externes.

Je pourrais bien sûr simplement "imprimer" toutes les données XML dans un tableau JavaScript entièrement déclaré dans l'en-tête du document, mais je crois que ce serait une très, très mauvaise solution. Et laid, d'ailleurs.

Mes questions sont donc:

  • Est-il même possible de faire ce que je suis penser?
  • Serait-ce SEO-friendly pour avoir tous les le contenu des pages du site chargé initialement dans le fichier XML?

Mon alternative serait de charger dynamiquement le contenu de la page spécifique en utilisant AJAX à la demande. Cependant, je trouve difficile de trouver un moyen qui serait le moins favorable au SEO. Je ne peux pas imaginer qu'un moteur de recherche exécuterait n'importe quel JavaScript.

Je suis vraiment désolé si ce n'est pas clair, mais ça me fait vraiment peur.
Merci d'avance.

Répondre

1

Est-il même possible de faire ce que je pense?

Bien sûr.

Est-ce que le fait que le contenu de toutes les pages du site soit chargé initialement dans le fichier XML serait favorable au SEO?

Non, ce serait une folie totale.

Je ne peux pas imaginer qu'un moteur de recherche puisse exécuter du code JavaScript.

Eh bien, tout à fait. C'est aussi très mauvais pour l'accessibilité: les navigateurs non-JS, ou les navigateurs avec une légère différence dans l'implémentation JS (par exemple de nouveaux mots réservés) qui font que votre script a une erreur et un boom! pas de page. Et à moins que vous fournissiez une navigation correcte à travers les liens de hachage, la facilité d'utilisation sera terrible aussi.

La création de contenu sur la page tout JavaScript peut être utile pour les applications web brutes (tristement célèbre, GMail), mais pour un site axé sur le contenu, elle serait largement désastreuse.Vous devez essentiellement créer les mêmes pages du côté client pour les navigateurs JS et du côté serveur pour tous les autres agents, à quel point vous avez perdu l'avantage de tout faire sur le client. Probablement mieux de le faire comme SO: principalement basé sur HTML, mais avec l'amélioration progressive côté client pour faire des tâches utiles comme vérifier les mises à jour du serveur et imprimer l'annonce "cette question a de nouvelles réponses".

+0

Vous connaissez certainement votre JavaScript ;-) Je pensais que c'était comme ça. De mon point de vue, la conclusion finale doit être que la fluidité des demandes de pages en chargeant le contenu des pages spécifiques n'est pas compatible avec le SEO (et manque également d'accessibilité, mais je ne suis pas d'accord avec vous sur ce point).). La seule chose qui me dérange alors, est comment je pourrais accéder au XML sous-jacent avec JavaScript? Pour ne pas l'utiliser comme je l'ai mentionné auparavant, je t'assure. Merci d'avoir répondu, d'ailleurs. –

+0

C'est assez simple: une requête AJAX rapide à un script côté serveur qui renvoie la portion exacte de XML requise pour cette fonctionnalité particulière (soit en XML, ou, plus généralement ces jours-ci en JSON, pour réduire le nombre d'ennuyeux- pour écrire du XML-walking côté client). – bobince

+0

Je ne suis pas vraiment sûr de ce que vous entendez par «fluidité» ... les utilisateurs sont habitués à naviguer comme dans les navigateurs et les navigateurs modernes minimisent le temps passé «entre les pages» pour rendre la navigation aussi rapide que possible. Vous embêtez avec le comportement attendu comme ceci à vos risques et périls! Par exemple si vous avez une page qui effectue un chargement de traitement AJAX sans l'indication visible habituelle du navigateur qu'une navigation est en cours, vous pouvez trouver vos utilisateurs assis là plusieurs fois en cliquant sur le lien et en pensant que cela ne fonctionne pas. – bobince

0

peut-être le scénario suivant fonctionne pour vous:

  1. un navigateur demande votre fichier xml.

  2. Une fois chargé, le xslt associé au fichier xml est exécuté. résultat: votre code HTML initial est sorti avec une balise de script. Dans le javascript, un appel ajax à l'emplacement actuel est fait pour obtenir le xml-dom «sous-jacent». à partir de là, votre javascript gère tout le traitement XML.

  3. Vous avez vérifié qu'à l'étape 3, le fichier XML n'est pas chargé à nouveau à partir du serveur mais provient du cache du navigateur.

c'est tout.