Bonjour tout le monde,
Je voudrais savoir s'il vous plait c'est quoi l'équivalent de la fonction isset en jsp??
Merci d'avance ;)Code:
2
3
4
5
6
7
8
9if(isset($mavariabble)) { ... } else { ... }
Version imprimable
Bonjour tout le monde,
Je voudrais savoir s'il vous plait c'est quoi l'équivalent de la fonction isset en jsp??
Merci d'avance ;)Code:
2
3
4
5
6
7
8
9if(isset($mavariabble)) { ... } else { ... }
En php isset teste si une valeur est nulle c'est bien ça? Dans ce casdevrait suffireCode:
2
3
4if (maVariable != null) { }
ben non en fait le isset() il teste si la variable existe ou pas. parceque moi je travaille avec un formulaire et je voudrai tester si les champs sont vide mais une fois que l'utilisateur a cliqué sur valider (c'est à dire une fois que la variable existe) et nom pas avant. sinon si je fais le test avec :
ça va m'afficher un message d'erreur comme quoi le champs n'est pas rempli, parceque forcément la variable sera null au tt début :? je sais pas comment faire un test une fois que le formulaire est posté une première fois et pas avant? comment ça se gère en jsp ça ?? :(Code:
2
3
4
5if (maVariable != null) { }
merci pour votre aide.
Pour tester si un champs de formulaire a bien été envoyé il faut que tu utilise
Si tu veux tester qu'il a bien été envoyé et qu'il n'est pas vide tu peux faireCode:
2if (request.getParameter("nomDuChamps") != null)
Code:
2if (request.getParameter("nomDuChamp") != null && !"".equals(request.getParameter("nomDuChamp")))
OButterlin et tchize_ les deux vous avez raison, par conséquent je rectifie mon bout de code avec le test amélioré :
Code:
2if( request.getParameter("nomDuChamps") != null && !"".equals(request.getParameter("nomDuChamps").trim()) )
alino: le code de guigui est correct et ne peux pas déclencher de NPE, si t'en a eu une, c'est que tu l'a mal tappé (faut de frappe dans un des deux paramètres)? Le new String ne sert strictement à rien dans ton code.
Il y a une différence avec le code alino-91, lui teste avec un trim()... ce qui est un peu plus précis...
(Pour une url du genre "http://.../laPage.jsp?nomDuChamp= &unAutreChamp=1)
D'ailleurs, sans le trim, on pouvait faire simplementCode:"".equals(request.getParameter("nomDuChamp"))
bref, ce que guigui avait écrit :mouarf: M'enfin on va pas tourner autour du pot, shada a sa solution
Mauvais joueur :mouarf: !Citation:
Envoyé par tchize_
Plus sérieusement, il peut être judicieux de se créer une petite classe dans le style
et de l'utiliser un peu partoutCode:
2
3
4
5
6
7
8
9
10public class Utils { public static boolean isSet(Object object) { if (object == null) return false; if (object instanceof String && ((String)object).trim().length() == 0) return false; return true; } }
Code:
2
3
4
5
6
7
8
OButterlin merci pour la méthode que tu as écrite, je vais l'implémenter de suite dans mon projet :ccool:
Mais de rien...Citation:
Envoyé par alino-91
Vous ne trouvez pas assez lourds les transferts reseau pour faire un test coté serveur juste pour voir si un champ a bien été rempli par un utilisateur?, c'est deconseillé d'ailleurs ça. une petite fonction js ferait très bien l'affaire, et on restera coté client tant que le formulaire n'aura pas recu l'aval de la fonction js. :calim2:
DevServlet: ton message n'a aucun rapport avec la question posée!
Je ne répondais plus à sa question puisque vous l'aviez déjà fait, je proposais une solution plus optimisée en terme de transfert réseau, dans ses prochains devs il y pensera surement.
C'est une des bases de programmation qu'on apprend en début à l'école tchize_, si je puis me permettre bien sur.
faire des test coté client c'est bien, mais ça ne dispense pas de faire les test aussi coté serveur, sauf bien sur si vous désirez fournir une application présentant des trous de sécurité. Ce n'est donc certainement pas "déconseillé" de faire des tests coté serveur pour savoir si les champs obligatoires sont remplis, c'est même au contraire fortement conseillé.
Hors sujet mais puisque vous être rentré en plein dedans, je vais donner mon avis (faudra juste penser à changer le titre du topic d'origine :aie:)
Sur le fond, je te rejoins. Maintenant, cela dépend surtout du contexte de l'application.Citation:
Envoyé par tchize_
Car il faut en être conscient, la sécurité a un coût.
Sur du B2C ou du B2B, effectivement, il faut être vigilant que notre appli ne soit pas une passoire.
Maintenant, on créé aussi des applis web (connerie ou non c'est le cas :aie:) répondant à des besoins pure intranet. Ces applis sont parfois utilisées et utilisables que par qu'une poignée de personnes dans l'entreprise et ne contiennent parfois pas données sensibles ou confidentielles.
Dans ces cas la, le client refuse parfois catégoriquement qu'on mette disons 10% de notre temps de dév à créer de la sécurité dont on a pas besoin.
Peso, je trouvais leurs choix justifiés.
oui, mais dans ce cas là tu met pas plus de temps à le faire coté serveur que coté client, pis c'est pas les framework qui manquent qui font déjà la validation dans ce genre de cas ;)
Faire des applications passoires a toujours existé, et ça existera encore...Citation:
Envoyé par thebloodyman
De là à dire que c'est la normalité, non.
Pour moi, le contrôle côté client est un plus (je ne dis pas que c'est inutile, bien au contraire, ça permet de limiter les aller/retour avec le serveur), mais le vrai contrôle incontournable est côté serveur. Toute entorse à cette règle est pour moi une erreur.
Si t'as une techno en front qui te génère à partir des contrôles java, les contrôles javascript, je suis d'accord puisque ca ne mange pas de pain (ou alors qu'un peu de mie :aie:).Citation:
oui, mais dans ce cas là tu met pas plus de temps à le faire coté serveur que coté client, pis c'est pas les framework qui manquent qui font déjà la validation dans ce genre de cas
Dans le cas inverse, ca dépend des pratiques .
En tous les cas de mon expérience, toute ligne de code tapée à la main non nécessaire est un coût : code + lourd, test unitaire , maintenance du code , bug...
Je te rejoins dans plus de 95% des cas je pense puisque que l'essentiel des applications web présentent des risques de piratage de données : tout l'internet, tout extranet, la majeure partie des intranets.Citation:
Pour moi, le contrôle côté client est un plus (je ne dis pas que c'est inutile, bien au contraire, ça permet de limiter les aller/retour avec le serveur),
Maintenant, pour les applis web intranet à 1 ou 2 utilisateurs qui font de la gestion de contenu, je vois très mal le mec contrefaire des requêtes ou envoyer n'importe quoi au serveur via des url tapées à la main puisque de toute façon, 1.ils ne gagneront rien à part faire planté ou buggé l'appli 2.ca leur tombera dessus si ils font n'importe quoi (il y a qu'eux qui utilisent l'appli :aie:) ?
On tombe dans le travers : je sécurise non par besoin mais par principe.
il me semble que tu oublie la raison principale pour laquelle on fait de la validation: l'erreur humaine. Un minimum de temps à faire de la validation, même basique, permet d'éviter de grosse pertes de temps en aval quand il faut corriger toute la DB parce qu'un opérateur à encodé une donnée de travers pendant 2 ans et que, maintenant qu'on a besoin de ces donénes, elle ne sont pas là / sont erronés. Ce que tu ne valide pas a aussi un coût, il est juste moins visible, mais il faut en tenir compte (formation supplémentaire pour expliquer ce qu'on ne peut pas faire, dans quel format il faut encoder les numéros de registre natinaux, intervention sur des processus bloqués car données mal encodées, etc.).
Tu sembles faire références là à des applis avec des données sensibles alors que moi non.Citation:
Envoyé par tchize_
C'est le rôle des contrôles coté client.Citation:
Ce que tu ne valide pas a aussi un coût, il est juste moins visible, mais il faut en tenir compte (formation supplémentaire pour expliquer ce qu'on ne peut pas faire, dans quel format il faut encoder les numéros de registre natinaux, intervention sur des processus bloqués car données mal encodées, etc.).
Les risques qu'il peut y avoir coté serveur, je les évoqués dans mon post précédent :
Donc pour moi, la question n'est pas de former les quelques utilisateurs de l'apli (puisque les contrôles clients sont déja la) mais simplement leur demander de ne pas essayer de pirater leur outil de travail.Citation:
Maintenant, pour les applis web intranet à 1 ou 2 utilisateurs qui font de la gestion de contenu, je vois très mal le mec contrefaire des requêtes ou envoyer n'importe quoi au serveur via des url tapées à la main puisque de toute façon, 1.ils ne gagneront rien à part faire planté ou buggé l'appli 2.ca leur tombera dessus si ils font n'importe quoi (il y a qu'eux qui utilisent l'appli ) ?
Je précise que je parle toujours d'appli intranet avec peu d'utilisateurs (entre 1 et 5) et pas de données sensibles.
Pour moi, le contrôle est nécessaire lorsque la valeur d'une propriété est déterminée par des règles (Je ne m'amuse pas à contrôler un champ texte s'il n'est pas nécessaire).
Certains contrôles peuvent être effectués côté client, en particulier :
- champ obligatoire
- champ numérique
- structure particulière de la donnée
- valeur comprise entre a et b
- liste de caractères autorisés restreints
- etc...
Par contre, certains contrôle ne peuvent pas être fait côté client (hors ajax) :
- intégrité référencielle
- liste de valeurs possibles dépendantes d'autres champs non présent dans l'ihm
- etc...
Donc, à choisir un endroit unique, je mettrais tout côté serveur.