IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

XMLRAD Discussion :

Bug dans xslc.js - SubmitForm()


Sujet :

XMLRAD

  1. #1
    Membre éclairé Avatar de Jeweller
    Inscrit en
    Août 2003
    Messages
    357
    Détails du profil
    Informations forums :
    Inscription : Août 2003
    Messages : 357
    Par défaut Bug dans xslc.js - SubmitForm()
    Hello,
    Je ne suis certainement pas le seul mais quite à, autant le relever! ;-)
    Je considère qu'il y a un "bug" (on va appeler ca comme ca) qui peut s'avérer tres grave dans la fonction SubmitForm() de xslc.js.

    Voici une situation simplifiée ou cela se produit:

    - Soit un formulaire avec 2 boutons, "Valider" et "Supprimer".
    - L'action renseignée dans ce formulaire est UpdateITEM.
    - Le bouton Valider fait un - Le bouton Supprimer fait un
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SubmitForm('MainForm','ACTION','DeleteITEM', 'CONFIRM','... message ....');
    L'utilisateur clique sur le bouton "Supprimer" et lors du message de confirmation annule finalement son action. Puis il choisit finalement (apres une modif ou non dans le formulaire) de cliquer sur le bouton "Valider" pour appliquer les modifications. Dans ce cas:
    DANGER==>Au lieu de valider les modifications, l'application supprime l'enregistrement!

    Vous l'avez compris, même si l'utilisateur annule lors de la confirmation le submit du formulaire, l'action de celui-ci a déjà été remplacée et cela peut avoir un effet tres désagréable! Dans cet exemple le XmlService invoqué n'est plus UpdateITEM mais DeleteITEM!

    Je propose que dans SubmitForm(), l'action et la target du formulaire ne soient affectés que si l'utilisateur valide la confirmation et non systématiquement. A mon sens il s'agit d'un bug, qu'en pensez vous ?

    Michael

  2. #2
    RDM
    RDM est déconnecté
    Membre Expert

    Profil pro
    Inscrit en
    Mars 2002
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2002
    Messages : 1 424
    Par défaut
    C'est un des gros problème que l'on rencontre avec le javascript: c'est le stockage de l'état dans des variables. Si l'on fait par exemple un précédent dans le navigateur et que l'on change d'action, on a le même phénomène. il faudrait en fait a chaque fois que l'on change une variable la restaurer dans on état initiale (celui du chargement de la page) après une validation du formulaire.

    on pourrait comme tu le suggères effectivement modifier le Submit form pour n'affecter l'action que lorsque la confirmation est faite mais le problème subsiste si je fais un précédent comme dans mon exemple.

    La question est plutot est-ce que le xslc.js doit prendre en compte la restauration des variables modifiés après submit ? ou bien est-ce quelquechose qui doit rester dans l'état pour d'autres raisons ?

  3. #3
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    284
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 284
    Par défaut
    Héhé, un bug dans SubmitForm(), comme tu y vas

    Voilà la version courante de la fonction, telle qu'elle est actuellement implementée dans les alpha de XMLRAD2007 :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
     
    function SubmitForm(FormName) {
      var F;
      var arg = arguments;
      var i;
      var ConfirmQuestion = '';
      var Action = null;
      var Target = null;
      if (!FormName || FormName == '')
        FormName = 'MainForm';
      if (typeof FormName == 'string')
        F = document.forms[FormName];
      else
        F = FormName;
      if (F == null)
        return false;
      for (i=0; i < arg.length; i++)
      {
        switch(arg[i])
        {
          case 'ACTION': Action = arg[++i]; break;
          case 'TARGET': Target = arg[++i]; break;
          case 'CONFIRM': ConfirmQuestion = arg[++i]; break;
        }
      }
      if (ConfirmQuestion != '')
      {
        if (confirm(ConfirmQuestion) == false)
          return false;
      }
      if (F.onsubmit && typeof F.onsubmit  == 'function')
        if (F.onsubmit() == false)
          return false;
      if (Action != null)
        F.action = Action;
      if (Target != null)
        F.target = Target;
      F.submit();
      return true;
    }
    Comme tu peux le constater, ton souhait est exhaucé ! Joyeux noel !!

    SubmitForm() devrait presque meme réinitialiser l'action par défaut apres le .submit(), car dans le cas d'utilisation de la fonction en PartialUpdate (= post du form dans un iframe caché), l'action et la target sont mises à jour, sans pour autant que la page se recharge et que les valeurs par defaut se réinitialise.

    Aujourd'hui, il est recommandé, une fois qu'on commence à utiliser SubmitForm en surchargeant les propriétés du form, de passer ces memes paramètres à tous les autres appels de la fonction, afin de s'assurer à la lecture du code et à l'exécution des traitements effectués dans chacun des cas.

  4. #4
    Membre éclairé Avatar de Jeweller
    Inscrit en
    Août 2003
    Messages
    357
    Détails du profil
    Informations forums :
    Inscription : Août 2003
    Messages : 357
    Par défaut
    Ah, ca correspond presque mot pout mot à ma modif... en même temps il y a pas 3 milles implémentations possible! Merci pour le bout de code!

    Et effectivement, pour répondre à cette problématique des variables et de leurs états, un usage systématique de SubmitForm avec l'ensemble des paramètres définis contourne la problématique dans le cas de l'appel au "précédent" et dans le cas du PartialUpdate.

    Concernant ta dernière question RDM, elle est complètement pertinente! En ce qui me concerne, je pencherais plutot pour une restauration de l'etat par défaut. Je n'ai pas de cas en tete ou cela me poserait d'autres problèmes (liés à la réutilisation de variables modifiés).


    Michael

  5. #5
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    284
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 284
    Par défaut
    Je suis d'accord aussi !
    Je n'ai pas en tete de cas où on s'appuit sur la modification potentielle des propriété d'un form par un premier appel à SubmitForm() pour les appels suivants.
    Je pense que c'est le cas pour toutes les autres fonctions modifiant l'etat.
    Je pense donc faire remonter cette reflexion à qui de droit !

Discussions similaires

  1. Bug dans le TCheckListBox ?
    Par Tardiff Jean-François dans le forum Composants VCL
    Réponses: 6
    Dernier message: 04/11/2004, 08h39
  2. Bug dans les expressions régulières ?
    Par SergioF dans le forum Linux
    Réponses: 8
    Dernier message: 12/05/2004, 15h14
  3. [PROPERTIES] Bug dans java.util.Properties ?
    Par mathieu dans le forum Collection et Stream
    Réponses: 6
    Dernier message: 28/04/2004, 15h11
  4. bug dans une base Access
    Par bizouard dans le forum Access
    Réponses: 5
    Dernier message: 29/12/2003, 12h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo