[DEBAT] JavaScript or not ?

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : [DEBAT] JavaScript or not ?

par sideb » 19 févr. 2005, 00:39

Pour ça faut que ça fonctionne :(
En ce moment je suis en train de passer certaines de mes pages en xhtml ou en xml, et les js sur des evenement ne fonctionne pas :(

Code : Tout sélectionner

<input type="submit" value="Valider !" onClick="javascript:alert('VALIDER !!!');" />
je viens à me demander si le javascript à un avenir... et si je vais pas supprimer tous mes js à contre coeur.

par iclo » 15 févr. 2005, 00:33

Le script doit bien être envoyé au client, non ?
En résumé : lors d'un submit d'un formulaire sans contrôle JavaScript, (du côté client), une requêtte http est envoyé au serveur, et cette requêtte va transiter via internet (ou le réseau local dans le cas d'un intranet) et utiliser des ressources du serveur pour être traitée.

Si tu fais une vérification en JavaScript, les envois rendus "inutiles" par des données non valides, seront filtrés, directement sur le pc du visiteur, et aucunes requêttes ne sera envoyés au serveur.
C'est bien-sûr, le cas idéal, où JavaScript est activé sur la machine cliente, si ce n'est pas le cas, une requêtte sera envoyé de toute façon au serveur, et c'est là que les vérfications seront faites.

Ce ne sont pas quelques if, au début d'un script php, qui posent problême mais bien, l'exécution inutile pur et simple du script sur le serveur, ce qu'on peut ainsi éviter.
Et je sais par expérience, que sur des sites, à fort traffic, avec des visiteurs pas très "doués' ( ou ayant du mal à comprendre ce qu'il leur est demandé dans le formulaire :D :D ) on peut éviter une grosse partie des requêtes inutiles, et c'est très souvent nécessaire, quand on a pas un serveur dédié super performant...

Coder proprement et optimisé, c'est jamais un luxe :D :D :D

par remram44 » 14 févr. 2005, 23:39

la bande passante, sollicitée pour rien
Le script doit bien être envoyé au client, non ?

par iclo » 14 févr. 2005, 23:03

Ce ne sont pas les X secondes gagnés pour le visiteur, qui ont de l'importance, mais une réquêtte http, envoyé pour rien au serveur, et sans parler de la bande passante, sollicitée pour rien.
Lorsqu'on travaille sur des scripts qui sont utilisés de manière massive sur un serveur, on apprend vite l'intérêt de ce genre de mesures "économiques" :wink: :wink: :wink:

par remram44 » 14 févr. 2005, 22:29

Les raisons ? :lol: Bien sûr que j'ai lu les posts précédant, mais je n'en ai trouvé qu'une seule : JS évite à l'utilisateur d'avoir à recharger la page. On gagne 3 secondes, quoi...
Je ne dirais bien sûr pas que ça ne sert à rien. Je dis juste que, personnellement (je donne mon avis, c'est ça un débat), j'utilise le JavaScript plutôt pour ce qui est menu ou autre (rechargement de cadre, et tout ce qui évite justement d'avoir à recharger toute la page pour utiliser un peu de PHP). Après, à vous de voir...

Re: Ca "n'allège" pas grand chose...

par iclo » 14 févr. 2005, 21:02

Tout à fait d'accord. Le JavaScript est le premier langage que j'ai appris... Mais je pense qu'il vaut mieux l'utiliser uniquement pour des effets, genre texte défilant ou fenêtre d'information, que pour les vérification qui ne sont de toute façon pas fiables.
As-tu bien lû les posts précédents ?? je crois que tu trouveras les raisons des tests en js avant un submit

par Greg » 14 févr. 2005, 16:58

Argh ... JavaScript pour des bidules qui défilent, des redimensionnements de fenetre et tout le bordel, je HAIS ça !!!
Pour moi, ça illustre d'autant mieux le coté inutile de la chose, vu qu'en plus, la compatibilité entre les navigateurs est encore moins respectée de ce coté là.

Je préfère encore l'employer pour éviter à un utilisateur de se planter en remplissant un formulaire, quitte à être obligé de doubler mes vérifications en PHP.

Ca "n'allège" pas grand chose...

par remram44 » 14 févr. 2005, 15:21

Tout à fait d'accord. Le JavaScript est le premier langage que j'ai appris... Mais je pense qu'il vaut mieux l'utiliser uniquement pour des effets, genre texte défilant ou fenêtre d'information, que pour les vérification qui ne sont de toute façon pas fiables.

par Greg » 14 févr. 2005, 15:18

Je comprends ton point de vue, mais si quelques vérifications de base en JavaScript peuvent alléger un peu la charge de ton serveur en évitant de balancer des infos bancales, pourquoi s'en priver ?

par remram44 » 11 févr. 2005, 18:26

Le truc, c'est que si JavaScript n'est pas activé, où même si il l'est, l'utilisateur peut toujours envoyer au serveur des données fausses.
Il faut donc toujours re-vérifier chaque champ... Je pense que c'est ce que voulais dire rod.

Par exemple, un bête formulaire :
<form method="post" action="recv.php" name="form1">
Rentrez une valeur dans ce champ (différente de "zabaza"): <input type="text" name="texte" value="10" onChange="Check()">
</form>
<script language="JavaScript" type="text/JavaScript">
function Check()
{
if(document.form1.texte.value=="zabaza")
{
document.form1.texte.value="interdit";
}
}
</script>
Ceci est bien sûr un exemple stupide.
Dans cet exemple, la page recv.php devra forcément refaire un test sur le champ "texte", car le JavaScript ne protège rien et l'utilisateur peut toujours, s'il le désire, envoyer "zabaza" au serveur...

Pour rentrer dans le débat, je ne vérifie jamais mes champs avec JavaScript : devoir tous les vérifier sans cesse sur le serveur me suffit déjà amplement...

par Greg » 11 févr. 2005, 16:16

On parlait d'économie de bande passante, mais on peut aussi faire de l'économie de traitement PHP et SQL à l'aide de JavaScript, sans compromettre l'intégrité des données transmises.

Je vois que je vous intrigue, donc avant de me faire incendier, je vais vous expliquer.
Pour info, j'en avais parlé à Perrick (http://www.onpk.net), qui m'a dit qu'il utilisait déjà cette technique.

Imaginez un petit formulaire HTML:

Code : Tout sélectionner

<form name="formulaire" action="page.php" method="post"> <input type="hidden" name="javascript_valide" value="0" /> <input type="text" name="champ" value="<?php echo $valeur; ?>" onchange="formulaire.champ_modifie.value=1"/> <input type="hidden" name="champ_modifie" value="0" /> </form>
(Je précise que je suis une quiche en JavaScript, apportez vos modifications si besoin)

Lors du chargement de la page, on va positionner un évènement onload() sur la balise <body> qui va mettre "javascript_valide" à 1 si le JavaScript est activé. Si ce n'est pas le cas, ça laissera la valeur à 0.
De la même manière, l'évènement onchange() sur le champ texte détectera si le champ à été modifié.

Dans la page page.php, il suffira de d'abord regarder ce que vaut $_POST[javascript_valide']. S'il est à un, on peut tenir compte de $_POST['champ_modifie'] pour faire ou nom une requete pour mettre à jour un champ d'une table.
Si $_POST['javascript_valide'] est égal à 0, on fait la requete quoi qu'il arrive.

De la même manière, avec plusieurs champ, on peut essayer de faire une requete composée pour ne mettre à jour que les champs qui auront changé.

Donc, je suis pour JavaScript (même si je suis une brèle), à condition que les traitements coté serveur soient fait ensuite, et que ça ne m'entrave pas ma navigation sur un site.

be or not to be

par scorpio » 11 févr. 2005, 11:31

ben, javascript c'est bien, on peut en avoir besoin a de nombreuses occasions.
C'est un lagage comme les autres, et je ne le trouve pas plus dur qu'un autre (il m'a fallut 2 aprés midi pour compredre à programmer correctement, et faire ce que je veux avec). Il est par contre trés rigureux au niveau de la sintaxe.
Mais, si jamais, le javascripr est executé coté client, et php c'est le coté serveur.
alors dépendant de ce que vous faites, il faut choisir l'un ou l'autre. Il y a plusieures solution de résoudre un probléme, mais une seulle est plus correcte et plus globale que les autres. Alors, à vous de voir.

par fab » 11 févr. 2005, 00:44

Pour le javascript je suis pour , mais en petite doses justes des plus qui snt vraiment ajouté au dernier moment lors de la conception d'un site web , des plus qui rendent le site plus agréable rien de plus.

Par contre genre les textes qui s'affiche a la Matrix etc... c'est une horreur !

Pour moi une merveille en javascript c'est gmail.com

Re: [DEBAT] JavaScript or not ?

par Xenon_54 » 09 févr. 2005, 18:49

Je parle ici de JavaScript utlisé pour les contrôles uniquement, pas pour faire les menus dynamiques ou faire des animations, qui polluent déjà tant le web.
Faux en ce qui concerne les menus dynamiques. Il existe plusieurs façons de créer des menus dynamiques accessibles et qui peuvent s'afficher correctement pour ceux qui ne possèdent pas Javascript.

Exemple:
http://openweb.eu.org/articles/menu_universel/

;)

par rod » 09 févr. 2005, 16:42

Oui c'est clair, je vais essayer de m'y remettre ! Merci pour vos réponses.