Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1190 connectés 

  FORUM HardWare.fr
  Programmation
  HTML/CSS

  gerer les erreurs en HTML

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

gerer les erreurs en HTML

n°1159831
nicoPS
Posté le 26-07-2005 à 10:30:41  profilanswer
 

salut a tous,
 
je vien juste de me mettre au HTML pour un stage dans une entreprise. malheuresement je n'ai pas beaucoup d'experience dans le langage.
 
je voudrais faire l'equivalent des exeptions en C++. En effet, je propose a l'utilisateur de rentrer des parametres en "input". si l'utilisateur n'a pas correctement rentre le format des donnees (entier,...) je voudrais que le systeme ce bloque et ne puisse continuer que si le bon format des donnees est utilise.
 
en fait j'ai cherche des exemples sur google mais je ne connais le nom de ce type d'utilisation en HTML. j'ai essaye avec "exception" mais je n'ai rien trouve.
 
d'avance merci  :jap:  
 

mood
Publicité
Posté le 26-07-2005 à 10:30:41  profilanswer
 

n°1159839
fred_p
Posté le 26-07-2005 à 10:35:06  profilanswer
 

la gestion des exceptions existe en javascript. Elle sont peu utilisables mais ont le merite d'exister. Pour ton problème de validité de formulaire, il y a deux écoles : le full js (ajax y compris) ou la validation côté serveur.

n°1159843
skeye
Posté le 26-07-2005 à 10:36:36  profilanswer
 

Le HTML n'est qu'un langage de présentation, il ne permet pas cela.
Mais si tu fais des formulaires, tu utilises à priori un autre langage qui s'exécute sur le serveur et te génère du html...lequel?


---------------
Can't buy what I want because it's free -
n°1159844
skeye
Posté le 26-07-2005 à 10:37:32  profilanswer
 

fred_p a écrit :

la gestion des exceptions existe en javascript. Elle sont peu utilisables mais ont le merite d'exister. Pour ton problème de validité de formulaire, il y a deux écoles : le full js (ajax y compris) ou la validation côté serveur.


Il faut forcément faire la validation coté serveur, donc autant commencer par ça.:o
Sinon il suffit qu'un abruti désactive le javascript pour que tu perdes toute vérification...


---------------
Can't buy what I want because it's free -
n°1159870
gatsusat
Posté le 26-07-2005 à 10:59:15  profilanswer
 

skeye a écrit :

Il faut forcément faire la validation coté serveur, donc autant commencer par ça.:o
Sinon il suffit qu'un abruti désactive le javascript pour que tu perdes toute vérification...


 
Ya pas forcément besoin d'être un abruti pour désactiver le javascript, on peut le faire intelligement, lorsque l'on trouve que le JS est trop reloud sur un site

n°1159876
skeye
Posté le 26-07-2005 à 11:01:38  profilanswer
 

gatsusat a écrit :

Ya pas forcément besoin d'être un abruti pour désactiver le javascript, on peut le faire intelligement, lorsque l'on trouve que le JS est trop reloud sur un site


 
J'ai jamais dit le contraire.[:klem3i1]
C'est juste une figure de style.[:petrus75]


---------------
Can't buy what I want because it's free -
n°1159897
robbyone
Non pas !
Posté le 26-07-2005 à 11:17:25  profilanswer
 

L'éternel combat entre le "vélo" et le "tunning-car"


---------------
La curiosité est un vilain défaut car l'erreur et la frustration sont de croire qu'elle pourra être satisfaite !
n°1159899
fred_p
Posté le 26-07-2005 à 11:18:59  profilanswer
 

skeye a écrit :

Il faut forcément faire la validation coté serveur, donc autant commencer par ça.:o
Sinon il suffit qu'un abruti désactive le javascript pour que tu perdes toute vérification...


 
je vais me repeter, mais si c'est dans le cadre d'un intranet, ta remarque ne rime a rien. c'est stupide de conseiller seulement une solution sans connaitre la topologie du problème. Dans le doute, je lui ai proposé les deux alternatives...

n°1159902
skeye
Posté le 26-07-2005 à 11:20:33  profilanswer
 

fred_p a écrit :

je vais me repeter, mais si c'est dans le cadre d'un intranet, ta remarque ne rime a rien. c'est stupide de conseiller seulement une solution sans connaitre la topologie du problème. Dans le doute, je lui ai proposé les deux alternatives...


Bah dans le doute je préfère proposer la seule dont les résultats sont garantis, question de point de vue...[:skeye]


---------------
Can't buy what I want because it's free -
n°1159905
fred_p
Posté le 26-07-2005 à 11:21:45  profilanswer
 

skeye a écrit :

Bah dans le doute je préfère proposer la seule dont les résultats sont garantis, question de point de vue...[:skeye]


 
Tout a fait

mood
Publicité
Posté le 26-07-2005 à 11:21:45  profilanswer
 

n°1159919
masklinn
í dag viðrar vel til loftárása
Posté le 26-07-2005 à 11:33:56  profilanswer
 

fred_p a écrit :

la gestion des exceptions existe en javascript. Elle sont peu utilisables mais ont le merite d'exister. Pour ton problème de validité de formulaire, il y a deux écoles : le full js (ajax y compris) ou la validation côté serveur.


Ya pas d'écoles qui tiennent, la validation doit être effectuée côté serveur point barre.
 
Ensuite pour améliorer l'expérience de l'utilisateur on peut en ajouter une côté client, mais ça ne dispense pas d'effectuer la validation à la réception :o

fred_p a écrit :

je vais me repeter, mais si c'est dans le cadre d'un intranet, ta remarque ne rime a rien. c'est stupide de conseiller seulement une solution sans connaitre la topologie du problème. Dans le doute, je lui ai proposé les deux alternatives...


 :non:  
 
Les intranets permettent l'utilisation du JS puisqu'on contrôle l'environnement (théoriquement, jusqu'à ce que le client migre) mais ne dispense en rien des validations serveur. Celles ci sont impératives. Que l'environnement soit contrôlé ou non, l'utilisateur reste un utilisateur et arrivera donc toujours à trouver un moyen pour faire sauter l'appli si on a pas des vérifications au plus strict.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
n°1159994
nicoPS
Posté le 26-07-2005 à 12:05:42  profilanswer
 

slt,
 
sympa d'avoir repondu rapidement.
j'ai pas tout compris car je ne suis pas un bosse en reseau, ni meme en JS (c'est effectivement pour une page intranet).
 
je crois que ca ne vaut pas le coup de faire tout un bordel pour ca. l'utilisateur ne devra pas etre trop con et rentrer du 1er coup le bon format.
 
merci
@+

n°1160000
skeye
Posté le 26-07-2005 à 12:06:56  profilanswer
 

nicoPS a écrit :

slt,
 
sympa d'avoir repondu rapidement.
j'ai pas tout compris car je ne suis pas un bosse en reseau, ni meme en JS (c'est effectivement pour une page intranet).
 
je crois que ca ne vaut pas le coup de faire tout un bordel pour ca. l'utilisateur ne devra pas etre trop con et rentrer du 1er coup le bon format.
 
merci
@+


 
C'est la pire solution que tu pouvais choisir. L'utilisateur est TOUJOURS trop con.:o


---------------
Can't buy what I want because it's free -
n°1160001
masklinn
í dag viðrar vel til loftárása
Posté le 26-07-2005 à 12:07:22  profilanswer
 

nicoPS a écrit :

l'utilisateur ne devra pas etre trop con et rentrer du 1er coup le bon format.


You're in for a world of pain, little girl... :o


Message édité par masklinn le 26-07-2005 à 12:07:52

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
n°1160009
fred_p
Posté le 26-07-2005 à 12:10:01  profilanswer
 

Je n'ai ecrit nul part qu'il ne fallait pas faire de validation côté serveur me semble t il... Je trouve quand même pénible, que pour la validation sommaire d'un champs dans un environement précis (quand tu livres une application, tu definis quand même le poste client de manière précise : os, navigateur supporté, configuration... ), on passe par des allés-retours clients-serveurs successifs pour afficher un warning.  
 
Je suis d'accord pour dire que c'est plus propre/secure de passer par le serveur, la plus part des serveur d'application actuels, spring en tête, facilitent se genre de mécanisme. D'un point de vu utilisateur, je trouve tout de même plus confortable d'avoir un première validation côté client pour finir par une validation côté serveur.  
 
Après, comme le dit si bien skeye, question de point de vue.


Message édité par fred_p le 26-07-2005 à 12:10:23
n°1160013
skeye
Posté le 26-07-2005 à 12:11:11  profilanswer
 

fred_p a écrit :

je trouve tout de même plus confortable d'avoir un première validation côté client pour finir par une validation côté serveur.


 
Tout à fait d'accord. Mais en aucun cas il n'est souhaitable de se passer de la validation serveur.


---------------
Can't buy what I want because it's free -
n°1160020
fred_p
Posté le 26-07-2005 à 12:12:36  profilanswer
 

comme dis plus haut, je n'ai jamais preconisé de se passer d'une validation côté serveur...

n°1160025
skeye
Posté le 26-07-2005 à 12:13:44  profilanswer
 

fred_p a écrit :

comme dis plus haut, je n'ai jamais preconisé de se passer d'une validation côté serveur...


 

fred_p a écrit :

la gestion des exceptions existe en javascript. Elle sont peu utilisables mais ont le merite d'exister. Pour ton problème de validité de formulaire, il y a deux écoles : le full js (ajax y compris) ou la validation côté serveur.


 
 
[:skeye]


---------------
Can't buy what I want because it's free -
n°1160043
fred_p
Posté le 26-07-2005 à 12:17:23  profilanswer
 

oui, je confirme. C'est peut être ambigu, mais ce que j'appelle validation côté serveur, ce n'est pas celle du formulaire mais du champs... Ok pour une validation du formulaire dans sa globalité, mais une validation champs par champs c'est lourdingue..

n°1160048
masklinn
í dag viðrar vel til loftárása
Posté le 26-07-2005 à 12:18:10  profilanswer
 

fred_p a écrit :

Je n'ai ecrit nul part qu'il ne fallait pas faire de validation côté serveur me semble t il...


fred_p a écrit :

comme dis plus haut, je n'ai jamais preconisé de se passer d'une validation côté serveur...


Comme Skeye l'a obligeament pointé... si quand même [:spamafote]


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
n°1160050
skeye
Posté le 26-07-2005 à 12:18:38  profilanswer
 

fred_p a écrit :

oui, je confirme. C'est peut être ambigu, mais ce que j'appelle validation côté serveur, ce n'est pas celle du formulaire mais du champs... Ok pour une validation du formulaire dans sa globalité, mais une validation champs par champs c'est lourdingue..


 
[:ktulu]
Bien entendu on va pas passer par le serveur à chaque fois qu'un champ du formulaire est renseigné!:o
On ne passe par le serveur que quand l'utilisateur valide le formulaire complet!:o


---------------
Can't buy what I want because it's free -
n°1160051
fred_p
Posté le 26-07-2005 à 12:19:05  profilanswer
 

Ok, alors je me suis mal exprimé :p

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  HTML/CSS

  gerer les erreurs en HTML

 

Sujets relatifs
transformation de texte en html et inversement[HTML] appel der procedure de LogOff
[HTML] alignement cellules d'un tableau.[HTML] Visibilité image
fct pour convert. caract. spec. HTML --> entités HTMLVous conseillez des plugin Firefox pour dev en JS/HTML ?
[HTML/CSS] Blocs superposés/Double arriere plan[HTML/PHP] Récupérer une donnée
vbs html word textbox[HTML]Afficher le chemin complet
Plus de sujets relatifs à : gerer les erreurs en HTML


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR