Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre
les vérification du genre if(champvide) alors erreur ?
J'ai actuellement :
les classes générées par hibernate dans un package 'model'
les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du
modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message
et je créerais une classe message qui elle serait manipulée par
l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me
gène : ce n'est pas réutilisable de module en module et en plus ça peut
devenir bavard si il y a de nombreux champs à valider...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
David Molinier
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
J'ai actuellement : les classes générées par hibernate dans un package 'model' les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message et je créerais une classe message qui elle serait manipulée par l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me gène : ce n'est pas réutilisable de module en module et en plus ça peut devenir bavard si il y a de nombreux champs à valider...
Si vous avez une indication...
Directement dans les formulaires, du moins, quand il s'agit de contrôle de surface (ton exemple de champ obligtoire vide, un champ numérique, une date, etc...). Ca peut être en javascript, ou si tu utilises Struts, à l'aide de règles dans le fichier "validator". Avec Struts toujours, tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ? Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique : laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le bouton de validation de ton formulaire pour lui dire ensuite que le champ aurait dû être numérique ? Pour des raisons de perfs ensuite : pas la peine de charger ton réseau avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un service ne peut être appelé que si tel ou tel paramètre est renseigné, autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions javascript quelque peu génériques, et les externaliser dans des fichiers .js.
Cependant, comme tu ne peux a priori pas te prémunir contre un utilisateur qui désactivera le javascript dans son browser, ou contre celui qui forgera une url avec des paramètres bidons, tu devras réitérer ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures, jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été saisi par l'utilisateur à ce niveau !
-- David Molinier <*>
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre
les vérification du genre if(champvide) alors erreur ?
J'ai actuellement :
les classes générées par hibernate dans un package 'model'
les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du
modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message
et je créerais une classe message qui elle serait manipulée par
l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me
gène : ce n'est pas réutilisable de module en module et en plus ça peut
devenir bavard si il y a de nombreux champs à valider...
Si vous avez une indication...
Directement dans les formulaires, du moins, quand il s'agit de contrôle
de surface (ton exemple de champ obligtoire vide, un champ numérique,
une date, etc...). Ca peut être en javascript, ou si tu utilises Struts,
à l'aide de règles dans le fichier "validator". Avec Struts toujours,
tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ?
Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé
dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour
vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique :
laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le
bouton de validation de ton formulaire pour lui dire ensuite que le
champ aurait dû être numérique ?
Pour des raisons de perfs ensuite : pas la peine de charger ton réseau
avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un
service ne peut être appelé que si tel ou tel paramètre est renseigné,
autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions
javascript quelque peu génériques, et les externaliser dans des fichiers
.js.
Cependant, comme tu ne peux a priori pas te prémunir contre un
utilisateur qui désactivera le javascript dans son browser, ou contre
celui qui forgera une url avec des paramètres bidons, tu devras réitérer
ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt
est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures,
jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été
saisi par l'utilisateur à ce niveau !
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
J'ai actuellement : les classes générées par hibernate dans un package 'model' les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message et je créerais une classe message qui elle serait manipulée par l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me gène : ce n'est pas réutilisable de module en module et en plus ça peut devenir bavard si il y a de nombreux champs à valider...
Si vous avez une indication...
Directement dans les formulaires, du moins, quand il s'agit de contrôle de surface (ton exemple de champ obligtoire vide, un champ numérique, une date, etc...). Ca peut être en javascript, ou si tu utilises Struts, à l'aide de règles dans le fichier "validator". Avec Struts toujours, tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ? Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique : laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le bouton de validation de ton formulaire pour lui dire ensuite que le champ aurait dû être numérique ? Pour des raisons de perfs ensuite : pas la peine de charger ton réseau avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un service ne peut être appelé que si tel ou tel paramètre est renseigné, autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions javascript quelque peu génériques, et les externaliser dans des fichiers .js.
Cependant, comme tu ne peux a priori pas te prémunir contre un utilisateur qui désactivera le javascript dans son browser, ou contre celui qui forgera une url avec des paramètres bidons, tu devras réitérer ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures, jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été saisi par l'utilisateur à ce niveau !
-- David Molinier <*>
Symon
Perso, je met toujours en place des contrôles de surfaces coté client (pour le confort de l'utilisateur), et un double check avec des exceptions et logs associés coté serveur (ne serait ce que pour avoir une "trace" des éventuels plaisantins sans avoir a scruter les logs apache).
Concernant la reutilisabilité, les js marchent parfaitement pour le web, et tu seras, de toutes façons, obligé de recoder ces contrôles "de surfaces" en cas de portage dans un autre environnement (appli swing autonome par exemple).
A+
Symon
David Molinier wrote:
Directement dans les formulaires, du moins, quand il s'agit de contrôle de surface (ton exemple de champ obligtoire vide, un champ numérique, une date, etc...). Ca peut être en javascript, ou si tu utilises Struts, à l'aide de règles dans le fichier "validator". Avec Struts toujours, tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ? Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique : laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le bouton de validation de ton formulaire pour lui dire ensuite que le champ aurait dû être numérique ? Pour des raisons de perfs ensuite : pas la peine de charger ton réseau avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un service ne peut être appelé que si tel ou tel paramètre est renseigné, autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions javascript quelque peu génériques, et les externaliser dans des fichiers .js.
Cependant, comme tu ne peux a priori pas te prémunir contre un utilisateur qui désactivera le javascript dans son browser, ou contre celui qui forgera une url avec des paramètres bidons, tu devras réitérer ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures, jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été saisi par l'utilisateur à ce niveau !
Perso, je met toujours en place des contrôles de surfaces coté client
(pour le confort de l'utilisateur), et un double check avec des
exceptions et logs associés coté serveur (ne serait ce que pour avoir
une "trace" des éventuels plaisantins sans avoir a scruter les logs apache).
Concernant la reutilisabilité, les js marchent parfaitement pour le web,
et tu seras, de toutes façons, obligé de recoder ces contrôles "de
surfaces" en cas de portage dans un autre environnement (appli swing
autonome par exemple).
A+
Symon
David Molinier wrote:
Directement dans les formulaires, du moins, quand il s'agit de contrôle
de surface (ton exemple de champ obligtoire vide, un champ numérique,
une date, etc...). Ca peut être en javascript, ou si tu utilises Struts,
à l'aide de règles dans le fichier "validator". Avec Struts toujours,
tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ?
Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé
dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour
vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique :
laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le
bouton de validation de ton formulaire pour lui dire ensuite que le
champ aurait dû être numérique ?
Pour des raisons de perfs ensuite : pas la peine de charger ton réseau
avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un
service ne peut être appelé que si tel ou tel paramètre est renseigné,
autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions
javascript quelque peu génériques, et les externaliser dans des fichiers
.js.
Cependant, comme tu ne peux a priori pas te prémunir contre un
utilisateur qui désactivera le javascript dans son browser, ou contre
celui qui forgera une url avec des paramètres bidons, tu devras réitérer
ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt
est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures,
jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été
saisi par l'utilisateur à ce niveau !
Perso, je met toujours en place des contrôles de surfaces coté client (pour le confort de l'utilisateur), et un double check avec des exceptions et logs associés coté serveur (ne serait ce que pour avoir une "trace" des éventuels plaisantins sans avoir a scruter les logs apache).
Concernant la reutilisabilité, les js marchent parfaitement pour le web, et tu seras, de toutes façons, obligé de recoder ces contrôles "de surfaces" en cas de portage dans un autre environnement (appli swing autonome par exemple).
A+
Symon
David Molinier wrote:
Directement dans les formulaires, du moins, quand il s'agit de contrôle de surface (ton exemple de champ obligtoire vide, un champ numérique, une date, etc...). Ca peut être en javascript, ou si tu utilises Struts, à l'aide de règles dans le fichier "validator". Avec Struts toujours, tu as ensuite les actions, et le "validate" associé.
Pourquoi ne pas mettre ces contrôles plus bas dans ton architecture ? Pour plusieurs raisons : le confort de ton utilisateur, qui sera guidé dans ses saisies au plus tôt (pas la peine d'attendre l'aller/retour vers ton WAS) ; imagine que tu veuilles qu'un champ soit numérique : laisseras-tu ton utilisateur saisir n'importe quoi et cliquer sur le bouton de validation de ton formulaire pour lui dire ensuite que le champ aurait dû être numérique ? Pour des raisons de perfs ensuite : pas la peine de charger ton réseau avec de telles requêtes et ton WAS avec ce genre de contrôle. Si un service ne peut être appelé que si tel ou tel paramètre est renseigné, autant vérifier les conditions d'appel AVANT l'appel proprement dit.
Pour la réutilisabilité, tu peux très bien faire des fonctions javascript quelque peu génériques, et les externaliser dans des fichiers .js.
Cependant, comme tu ne peux a priori pas te prémunir contre un utilisateur qui désactivera le javascript dans son browser, ou contre celui qui forgera une url avec des paramètres bidons, tu devras réitérer ces contrôles au plus tôt dans ton modèle (approche MVC) : au plus tôt est *toujours* le mieux !
On trouvera d'autres types de contrôles dans les couches inférieures, jusqu'au DAO, mais surtout pas le contrôle qu'un champ obligatoire a été saisi par l'utilisateur à ce niveau !
Lionel
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé
mettre les vérification du genre if(champvide) alors erreur ?
<mode troll>
Aucun controle dans l'appli, utilise les contraintes de ta base :-)
</mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis
coté serveur, "au plus tot".
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Zouplaz
Lionel - SPAMcoollATfreePOINTfr :
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les contrôles serveur, puis une fois que tout est sûr implémenter les contrôles clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même temps ?
Lionel - SPAMcoollATfreePOINTfr :
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé
mettre les vérification du genre if(champvide) alors erreur ?
<mode troll>
Aucun controle dans l'appli, utilise les contraintes de ta base :-)
</mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis
coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les
contrôles serveur, puis une fois que tout est sûr implémenter les contrôles
clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même
temps ?
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les contrôles serveur, puis une fois que tout est sûr implémenter les contrôles clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même temps ?
David Molinier
Lionel - SPAMcoollATfreePOINTfr :
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les contrôles serveur, puis une fois que tout est sûr implémenter les contrôles clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même temps ?
Tout dépend de comment est organisé ton développement : 2 équipes en //, 1 seul développeur pour l'IHM et les services/DAO ?
De toutes façons, tes specs côté client ET côté serveur feront état de ces contrôles, donc la question ne se pose pas : quand tu développes un formulaire, tu codes les contrôles de champs qui lui sont associés. Quant tu développes un service, tu codes les contrôles des paramètres attendus.
Tu peux aussi commencer par développer un ensemble de fonctions javascript qui vont couvrir tous les contrôles de surface que tu as identifiés pour ton application. Tu développes ensuite les méthodes de classe pour tous les contrôles que tu vas faire côté serveur. Et ensuite, roule, tu développes tes écrans et tes services.
Mais tout ça relève de l'organisation de tes développements, et n'est pas lié à la problématique de contrôle.
-- David Molinier <*>
Lionel - SPAMcoollATfreePOINTfr :
Zouplaz wrote:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé
mettre les vérification du genre if(champvide) alors erreur ?
<mode troll>
Aucun controle dans l'appli, utilise les contraintes de ta base :-)
</mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis
coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les
contrôles serveur, puis une fois que tout est sûr implémenter les contrôles
clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même
temps ?
Tout dépend de comment est organisé ton développement : 2 équipes en //,
1 seul développeur pour l'IHM et les services/DAO ?
De toutes façons, tes specs côté client ET côté serveur feront état de
ces contrôles, donc la question ne se pose pas : quand tu développes un
formulaire, tu codes les contrôles de champs qui lui sont associés.
Quant tu développes un service, tu codes les contrôles des paramètres
attendus.
Tu peux aussi commencer par développer un ensemble de fonctions
javascript qui vont couvrir tous les contrôles de surface que tu as
identifiés pour ton application. Tu développes ensuite les méthodes de
classe pour tous les contrôles que tu vas faire côté serveur. Et
ensuite, roule, tu développes tes écrans et tes services.
Mais tout ça relève de l'organisation de tes développements, et n'est
pas lié à la problématique de contrôle.
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
<mode troll> Aucun controle dans l'appli, utilise les contraintes de ta base :-) </mode troll>
Comme dans les réponses précédentes, je fais un double controle: JS puis coté serveur, "au plus tot".
Donc, dans ce cas durant le développement il faut focaliser sur les contrôles serveur, puis une fois que tout est sûr implémenter les contrôles clients... Tu procèdes dans cet ordre ou bien tu fais les deux en même temps ?
Tout dépend de comment est organisé ton développement : 2 équipes en //, 1 seul développeur pour l'IHM et les services/DAO ?
De toutes façons, tes specs côté client ET côté serveur feront état de ces contrôles, donc la question ne se pose pas : quand tu développes un formulaire, tu codes les contrôles de champs qui lui sont associés. Quant tu développes un service, tu codes les contrôles des paramètres attendus.
Tu peux aussi commencer par développer un ensemble de fonctions javascript qui vont couvrir tous les contrôles de surface que tu as identifiés pour ton application. Tu développes ensuite les méthodes de classe pour tous les contrôles que tu vas faire côté serveur. Et ensuite, roule, tu développes tes écrans et tes services.
Mais tout ça relève de l'organisation de tes développements, et n'est pas lié à la problématique de contrôle.
-- David Molinier <*>
lepere
Coté client tous les champs à vérifier portent un nom particulier dans lequel sont spécifiés le ou les contrôles à effectuer. Dans un script javascript générique toujours coté client, avant d'exécuter le post, pour chaque champ du formulaire je récupère la saisié effectuée et le ou les contrôles à effectuer sur cette saisie via Javascript.
De là, j'envoie ça au serveur selon une syntaxe particulière par le bias d'une applet microscopique chargée sur le poste client. En fait via cette applet j'appelle un servlet de contrôle sur le serveur.
Le serveur, via ce servlet me répond ok ou pas pour le ou les contrôles à effectuer. Si ok je passe au contrôle suivant a effectuer le cas écheant. Si pas Ok le champ spécifique change de couleur + message au client et je renvoie un false au navigateur pour que le post ne soit pas exécuté. Ainsi la page n'est pas envoyée au serveur.
Cela me permet de simuler le mode connecté dans le navigateur qui est normalement (Stateless !). Le trafic reseau généré par ces contrôles est très faible. Le système est très fiable et très classe à utiliser.
De plus, lorsque le contrôle est écrit sur le servlet qui gère tous les contrôles possibles, il est réutilisable à souhait. Le nom du champ à contrôler doit comporter le nom du contrôle selon une syntaxe spéciale.
Voilà en quelques mots, et ça marche super bien, j'ai fait cela pour un logiciel conçu en mode WEB.
Je reste à disposition pour plus d'infos. TGO. "Zouplaz" a écrit dans le message de news:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
J'ai actuellement : les classes générées par hibernate dans un package 'model' les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message et je créerais une classe message qui elle serait manipulée par l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me gène : ce n'est pas réutilisable de module en module et en plus ça peut devenir bavard si il y a de nombreux champs à valider...
Si vous avez une indication...
Merci
Coté client tous les champs à vérifier portent un nom particulier dans
lequel sont spécifiés le ou les contrôles à effectuer.
Dans un script javascript générique toujours coté client, avant d'exécuter
le post, pour chaque champ du formulaire je récupère la saisié effectuée et
le ou les contrôles à effectuer sur cette saisie via Javascript.
De là, j'envoie ça au serveur selon une syntaxe particulière par le bias
d'une applet microscopique chargée sur le poste client.
En fait via cette applet j'appelle un servlet de contrôle sur le serveur.
Le serveur, via ce servlet me répond ok ou pas pour le ou les contrôles à
effectuer.
Si ok je passe au contrôle suivant a effectuer le cas écheant.
Si pas Ok le champ spécifique change de couleur + message au client et je
renvoie un false au navigateur pour que le post ne soit pas exécuté.
Ainsi la page n'est pas envoyée au serveur.
Cela me permet de simuler le mode connecté dans le navigateur qui est
normalement (Stateless !).
Le trafic reseau généré par ces contrôles est très faible.
Le système est très fiable et très classe à utiliser.
De plus, lorsque le contrôle est écrit sur le servlet qui gère tous les
contrôles possibles, il est réutilisable à souhait.
Le nom du champ à contrôler doit comporter le nom du contrôle selon une
syntaxe spéciale.
Voilà en quelques mots, et ça marche super bien, j'ai fait cela pour un
logiciel conçu en mode WEB.
Je reste à disposition pour plus d'infos.
TGO.
"Zouplaz" <pouet@pouet.com> a écrit dans le message de news:
Xns95FF710FE17FCZoupla@212.27.42.66...
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé
mettre
les vérification du genre if(champvide) alors erreur ?
J'ai actuellement :
les classes générées par hibernate dans un package 'model'
les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du
modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message
et je créerais une classe message qui elle serait manipulée par
l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me
gène : ce n'est pas réutilisable de module en module et en plus ça peut
devenir bavard si il y a de nombreux champs à valider...
Coté client tous les champs à vérifier portent un nom particulier dans lequel sont spécifiés le ou les contrôles à effectuer. Dans un script javascript générique toujours coté client, avant d'exécuter le post, pour chaque champ du formulaire je récupère la saisié effectuée et le ou les contrôles à effectuer sur cette saisie via Javascript.
De là, j'envoie ça au serveur selon une syntaxe particulière par le bias d'une applet microscopique chargée sur le poste client. En fait via cette applet j'appelle un servlet de contrôle sur le serveur.
Le serveur, via ce servlet me répond ok ou pas pour le ou les contrôles à effectuer. Si ok je passe au contrôle suivant a effectuer le cas écheant. Si pas Ok le champ spécifique change de couleur + message au client et je renvoie un false au navigateur pour que le post ne soit pas exécuté. Ainsi la page n'est pas envoyée au serveur.
Cela me permet de simuler le mode connecté dans le navigateur qui est normalement (Stateless !). Le trafic reseau généré par ces contrôles est très faible. Le système est très fiable et très classe à utiliser.
De plus, lorsque le contrôle est écrit sur le servlet qui gère tous les contrôles possibles, il est réutilisable à souhait. Le nom du champ à contrôler doit comporter le nom du contrôle selon une syntaxe spéciale.
Voilà en quelques mots, et ça marche super bien, j'ai fait cela pour un logiciel conçu en mode WEB.
Je reste à disposition pour plus d'infos. TGO. "Zouplaz" a écrit dans le message de news:
Bonjour, quand je valide un formulaire (HTTP POST), où suis-je sensé mettre les vérification du genre if(champvide) alors erreur ?
J'ai actuellement : les classes générées par hibernate dans un package 'model' les classes DAO dans 'dao'
Je me disais que je pourrais dériver une classe pour chaque classe du modèle et y mettre les validations ici...
Par exemple model.message deviendrait model._message et je créerais une classe message qui elle serait manipulée par l'application et par les classes DAO.
Parce que en les mettant en "amont", c'est à dire dans l'application ça me gène : ce n'est pas réutilisable de module en module et en plus ça peut devenir bavard si il y a de nombreux champs à valider...
