Discussion :

[Jeweller]

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

Code :

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

SubmitForm(MainForm);

- 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

[RDM]

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 ?

[Nicolas.Cogi]

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.

[Jeweller]

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

[Nicolas.Cogi]

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 !