Discussion :

[shada]

Bonjour tout le monde,

Je voudrais savoir s'il vous plait c'est quoi l'équivalent de la fonction isset en jsp??

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
if(isset($mavariabble))
{
...
}
else
{
...
}

Merci d'avance

[guigui5931]

En php isset teste si une valeur est nulle c'est bien ça? Dans ce cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (maVariable != null)
{
 
}

devrait suffire

[shada]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (maVariable != null)
{
 
}

ç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 ??

merci pour votre aide.

[guigui5931]

Pour tester si un champs de formulaire a bien été envoyé il faut que tu utilise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (request.getParameter("nomDuChamps") != null)

Si tu veux tester qu'il a bien été envoyé et qu'il n'est pas vide tu peux faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (request.getParameter("nomDuChamp") != null && !"".equals(request.getParameter("nomDuChamp")))

[Invité]

OButterlin et tchize_ les deux vous avez raison, par conséquent je rectifie mon bout de code avec le test amélioré :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if( request.getParameter("nomDuChamps") != null && !"".equals(request.getParameter("nomDuChamps").trim()) )

[tchize_]

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.

[OButterlin]

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 simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"".equals(request.getParameter("nomDuChamp"))

[tchize_]

bref, ce que guigui avait écrit M'enfin on va pas tourner autour du pot, shada a sa solution

[OButterlin]

bref, ce que guigui avait écrit M'enfin on va pas tourner autour du pot, shada a sa solution

Mauvais joueur !

Plus sérieusement, il peut être judicieux de se créer une petite classe dans le style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public 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;
    }
}

et de l'utiliser un peu partout

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
...
<%
if (Utils.isSet(request.getParameter("unChamp")))
{
  ...
}
%>

[Invité]

OButterlin merci pour la méthode que tu as écrite, je vais l'implémenter de suite dans mon projet

[OButterlin]

OButterlin merci pour la méthode que tu as écrite, je vais l'implémenter de suite dans mon projet

Mais de rien...

[DevServlet]

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.

[tchize_]

DevServlet: ton message n'a aucun rapport avec la question posée!

[DevServlet]

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.

[tchize_]

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é.

[thebloodyman]

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 )

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é.

Sur le fond, je te rejoins. Maintenant, cela dépend surtout du contexte de l'application.
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 ) 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.

[tchize_]

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

[OButterlin]

...
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 ) 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.

Faire des applications passoires a toujours existé, et ça existera encore...
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.

[thebloodyman]

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

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 ).
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...

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),

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.
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 ) ?
On tombe dans le travers : je sécurise non par besoin mais par principe.

[tchize_]

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.).