2010-11-25 15 views
1

J'ai rencontré un problème étrange avec javascript.comment vérifier si le fichier js est téléchargé à la fin du client

La page de problème utilise du code jQuery pour collecter des données et elle vérifie la validation des entrées. Si la validation est vraie, elle est publiée sur le serveur. Certains de nos utilisateurs ont signalé (10% ou peut-être beaucoup moins), ils ne pouvaient pas soumettre sur le site Web.

Nous avons parlé avec l'un des utilisateurs qui ont eu le problème, et étaient encore plus confus après.

PC de testeur: XP, IE8, FireFox

La première fois qu'il a utilisé IE et la validation JavaScript n'a pas le feu, il n'a pas pu soumettre des données au serveur ni parce que la validation a été mis en faux par défaut. (il est supposé avoir un message d'erreur apparaissant si la validation est fausse)

Ensuite, il a testé avec F.F. (F.F a travaillé tout de suite).

Revenant à IE à nouveau, le script de validation a commencé à fonctionner et l'envoi a de nouveau réussi. Donc, après tout le testeur n'a plus de problème, et ne pouvait pas non plus répliquer.

Je me demande si un logiciel ou un programme peut empêcher le téléchargement du fichier js? Parce que la page est également hébergée dans un i-frame dans un autre site Web, c'est pourquoi je pense que certains antivirus peuvent penser qu'il s'agit d'une menace à travers le domaine et a arrêté le travail de publication.

Si oui, comment puis-je faire une vérification pour m'assurer que tous les fichiers js requis sont téléchargés avant que l'utilisateur ne fasse une soumission? Quoi d'autre devrais-je regarder, puisque le problème se produit sur l'extrémité du client seulement, sans validation de fin de serveur pour le moment.

@drachenstern: merci pour le modifier

+1

Amélioration progressive? – strager

Répondre

0

Il est possible qu'il y ait un certain retard dans le chargement du javascript sur le client sde. produits anti-virus "Internet secutiry" (peuvent) faire beaucoup de contrôles.

Il est très possible que le produit de sécurité Internet analyse un appel, puis décide "ok, c'est sûr" et le fichier javascript est téléchargé. Il pourrait être un retard dans cela.

Comment éviter la situation?

  1. Ne pas lier votre formulaire soumettre à javascript. Laissez-le arriver toujours, avec ou sans javascript. Si javascript est prêt, l'utilisateur aura une bonne expérience (validation immédiate). Si ce n'est pas encore prêt, l'utilisateur sera toujours en mesure de faire la soumission, faire la validation et renvoyer les messages d'erreur de manière «traditionnelle» en actualisant la page.

  2. Attendez que l'utilisateur charge le javascript. Vous pouvez avoir une petite icône de "chargement" quelque part dans la page pour indiquer à l'utilisateur qu'il doit attendre. L'utilisateur peut entrer les données, mais ne peut pas encore soumettre. En arrière-plan, continuez à vérifier si le javascript est chargé (setTimeout et en recherchant une variable spécifique). Une fois qu'il est chargé, vous pouvez utiliser les validations javascript

  3. Une combinaison des deux: Autoriser l'envoi non-javascript jusqu'à ce que vous sachiez que le javascript est chargé. Une fois cela fait, utilisez les validations javascript.

1

Vous pourriez désactiver le bouton soumettre, activer seulement après jQuery est complètement chargé et exécuté.

Par exemple:

<input type="submit" disabled />

puis, dans votre Javascript,

 
$(function() { 
    $('input:submit').attr('disabled', false); 
}); 

Cependant, sachez que

  1. utilisateur ne sera pas en mesure de présenter quoi que ce soit un navigateur qui ne prend pas en charge vascript
  2. Vous ne devriez pas dépend de Javascript pour vérifier le le contenu de l'utilisateur; validez toujours les données sur le serveur.
+1

Au premier point: pour contourner cela, il suffit d'utiliser javascript pour désactiver le soumettre en premier lieu. – nnevala

+0

Comment connaissez-vous le javascript qui désactive le contrôle chargé ou non? – timdream

0

Je suggérerais d'abord que vous devriez toujours valider tout sur le serveur. La seule raison de valider sur le client est de rendre la réponse à l'utilisateur plus rapide sur les mauvaises entrées.De plus, pour s'assurer que chaque fichier est téléchargé et traité, vous pouvez toujours mettre un var global dans chaque fichier, puis les vérifier dans le document pour voir si chaque variable a été trouvée. C'est un retour brut mais ça marcherait.

Vous n'avez pas spécifié quelle version de IE l'utilisateur utilisait, mais le problème du fichier qui n'est pas chargé immédiatement dans IE me semble normal, même si c'est un peu bizarre. Je l'ai déjà rencontré plusieurs fois, et la seule solution est un ctrl-F5 pour moi. Je ne sais pas quoi dire d'autre ici. Ce serait merveilleux si nous pouvions toujours faire en sorte que tous les navigateurs répondent de la même façon, mais nous ne pouvons pas, alors nous continuons. De plus, sur quel système d'exploitation faisaient-ils tous ces tests? Et sur quel navigateur testez-vous?

Quel comportement voyez-vous dans IE? Si vous utilisez IE8 ou plus tard, vous aurez certainement des outils de débogage, et vous pourrez toujours utiliser FirebugLite pour déboguer vos pages dans IE sans utiliser les outils IE. Ensuite, vous pouvez voir ce que fait la page dans IE. Peut-être lancer une erreur d'analyse javascript? Y at-il des icônes sur la fenêtre chrome dans IE qui donnerait un tipoff?

Mais je pense que si vous essayez de corriger le deuxième paragraphe, vous le faites mal si vous comptez sur le javascript pour traiter les validations. Mais je ne suis qu'un gars.

+0

Je pense que c'est l'idéal pour valider à tous les 3 niveaux; côté client, côté serveur et contraintes db. –

+0

@MattBriggs ~ Je suis d'accord, mais la seule raison de valider sur le client est d'améliorer le processus pour l'utilisateur et de donner un retour immédiat. Il est toujours si facilement contourné que d'être simplement une commodité. – jcolebrand

+0

le problème est, il a arrêté au niveau du client-fin, les données n'ont pas été soumises à la fin du serveur du tout –