J'ai plutôt une mauvaise image du JavaScript. Suite notament aux problèmes de compatibilité et aussi oh fait que l'on peut le désactiver sur les navigateurs.
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.
Personnellement je suis plus pour faire les contrôles côté Serveur, c'est à dire en PHP. Que de faire les contrôles côté clients en JavaScript. Même si ça demande le rechargement de la page.
En tout cas par ce post, j'aimerais avoir un peu vos avis sur ce sujet.
la communauté d'entraide francophone dédiée au PHP
[DEBAT] JavaScript or not ?
A vrai dire utiliser du javascript pour contrôler des champs de formulaire est une bonne idée mais il faut toujours penser à faire une vérification côté serveur une fois le formulaire soumis. Après c'est avant tout une question de temps car appliquer les deux méthodes est certaine normalement un avantage mais prend également beaucoup plus de temps selon la taille des formulaires.
C'est sur que perso, je vois pas l'interet d'un controle en JS si c'est pour refaire le meme en PHP derrière.
Sinon une alternative à ce genre de choix peut être QuickForm. Un package de PEAR qui permet la génération de formulaire. Je l'ai testé et je trouve ca pas mal du tout et rapide en plus.
Sinon une alternative à ce genre de choix peut être QuickForm. Un package de PEAR qui permet la génération de formulaire. Je l'ai testé et je trouve ca pas mal du tout et rapide en plus.
Economiser de la bande passante (très léger, sauf si c'est un formulaire qui est utilisé très souvent). Economie de temps pour l'utilisateur (une alerte javascript, ça s'affiche plus vite que de recharger la page avec un message d'erreur).C'est sur que perso, je vois pas l'interet d'un controle en JS si c'est pour refaire le meme en PHP derrière.
L'intérêt est minime, donc il ne faut pas perdre trop de temps dessus, mais un petit bout de code rajouté vite fait ça ne fait pas de mal
L'intéret et pourtant simple, lorsqu'on fait un controle en JS on test le client jusqu'a la tout va bien ... oui mais le client peut tromper ton script JS de bien des facons ! Via du farming avec un autre script qui trompe des variable de ton script ou par de multitudes méthodes ... il est donc obligatoire de controler de différente manière lorsqu'on utilise que JS pour un paiement sécurisé par exempleC'est sur que perso, je vois pas l'interet d'un controle en JS si c'est pour refaire le meme en PHP derrière.
controler un formulaire en JS est pour moi conviviale pour faire apparaitre un bouton submit lorsque tout les champs sont bien renseigné par exemple (ce qui evite d'afficher et donc de refaire calculer 100 fois la page à php parce que ton internaute est une brèle et qu'il n'a pas vue la case a cocher par exemple... on peut aussi faire apparaitre des messages en fonction des erreur de l'internaute en "temps réel" ce qui est un avantage collossale je trouve pour la convivialité d'une page comme un formulaire.
Je suis d'accord que JS n'est pas le langage le plus facile surtout lorsqu'on veut créer un script portable sur différent navigateur mais c'est comme tous c'est un métier et si on a envie de bien faire on se donne les moyens.
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.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.
Exemple:
http://openweb.eu.org/articles/menu_universel/
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
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
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.
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.
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:
(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.
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>
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.
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 :
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...
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>
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...
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.
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.
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.
As-tu bien lû les posts précédents ?? je crois que tu trouveras les raisons des tests en js avant un submitTout à 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.