Discussion :

[Sylvain James]

Ce post pour parler d'un cas pratique plutôt intéressant mettant en oeuvre XMLC_Pivot, les champs de formulaire de type checkbox et l' XMLInstruction Match.

J'ai une page qui présente une liste de lignes. Sur chaque ligne, on trouve une case à cocher, un champ de saisie, et une combo (disons que globalement, chaque ligne comprend plusieurs éléments de formulaires).

Afin de poster l'intégralité de ces lignes via un formulaire, j'ai ajouté un pivot XMLC_Pivot = nom de mon pivot.

Dans le XMLService invoqué par le formulaire en question, j'ai ajouté une XMLInstruction Match. Cette instruction va matcher le pivot tout en alimentant le context pour chaque item rencontré.
Imaginez que sur la première ligne, la checkbox était cochée avec value = 1.
A ce stade, le context va contenir la valeur 1 pour le nom de la checkbox.

L'instruction match passe à la ligne (item) suivante. Admettons que sur cette ligne, la checkbox n'était pas cochée. He bien dans ce cas particulier, le formulaire ne transmet pas ni le nom ni la valeur de la checkox.
Ce qui fait que notre instruction match, ne rencontrant pas d'élément correspondant au nom de la checkbox, ne renseigne rien à son sujet dans le context.
Ainsi le context contient toujours la valeur de la ligne précédente (cochée= 1)... alors qu'en réalité, c'est l'inverse ! Capito ?

Une solution possible pour rémédier à ce cas :
Implémenter un gestionnaire Match.BeforeInternalInstruction (ou After) et coder

Code :

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

Context.SetValue("CHECKBOXNAME", "");

Si vous avez des remarques ou rencontré des situations similaires... ?

[Jeweller]

Salut!

En lisant ton post, je me suis dis "Tiens, je n'ai jamais constaté ce phénomène... bizarre..." Donc pour vérifier tes dires j'ai fait le test chez moi et forcément je constate le même phénomène! Donc je te dis MERCI! Tu viens de me permettre de corriger un cholie beug que personne n'avait encore vu!
Pour ce qui est de la solution, je n'ai pas d'autres idées pour le moment.

Michael

[RDM]

cela ne ressemble pas à ce thread? :
http://www.developpez.net/forums/showthread.php?t=2010

mis à part ca, je comprend que ca puisse poser problème.

dans la version 2007 une nouvelle instruction Match a vu le jour qui se fait par description des champs attendu dans le context
Vous spécifiez la Source Context et vous décrivez les champs.
par exemple si vous avez des champs de ce type:
ORGANIZATION[1].ORG_ID
ORGANIZATION[1].ORG_NAME
ORGANIZATION[2].ORG_ID
ORGANIZATION[2].ORG_NAME
Le Record Name est ORGANIZATION
vous ajoutez les champs ORG_ID et ORG_NAME dans field
le record Count pemet de spécifier un nombre Max de records sur le quel il itère pour la recherche des champs:
si le nombre (exemple 10) est spécifié, il va faire ORGANIZATION[1].ORG_ID à ORGANIZATION[10].ORG_ID et même si le champ est vide ou non transmis
si le nombre n'est pas spécifié il va s'arrêter quand aucun champ n'est trouvé dans le Context
De plus si le champ n'existe pas dans le context, il met le champ à blanc !
l'ancienne méthode correspond a une Source Input.

[Jeweller]

Fichtre, un thread qui remonte à janvier 2003! Impressionnant. Mais c'est ca effectivement
Merci pour l'info sur la 2007.

Michael

[Nicolas.Cogi]

Pour compléter le post de RDM sur le nouveau match :

• Plus besoin de XMLC_Pivot dans le formulaire.
• Possibilité d'imbriquer les Match pour gérer les hiérarchie ORG[1].PSN[1].PSN_FIRST_NAME
• Permet de matcher sur des CommaText (test@test.com;test2@test.com; ). Pratique pour matcher sur un array.join(";") javascript !

[Sylvain James]

cela ne ressemble pas à ce thread? :
http://www.developpez.net/forums/showthread.php?t=2010

ouah ! ...oui oui c'est bien ça :-)

dans la version 2007 une nouvelle instruction Match a vu le jour qui se fait par description des champs attendu dans le context
...
si le nombre (exemple 10) est spécifié, il va faire ORGANIZATION[1].ORG_ID à ORGANIZATION[10].ORG_ID et même si le champ est vide ou non transmis
si le nombre n'est pas spécifié il va s'arrêter quand aucun champ n'est trouvé dans le Context
De plus si le champ n'existe pas dans le context, il met le champ à blanc !
l'ancienne méthode correspond a une Source Input.

Excellent, ça sera en effet plus intuitif que le Pivot.
Mais du coup ça me fait penser à 2 choses :
- Est ce que l'itération sera forcément incrémentale numériquement parlant (ITEM[x]... ITEM[x+1] etc.) ? Car jusqu'à maintenant le pivot nous permettait d'itérer quelque soit la valeur de l'indice, et c'était plutôt pratique dans certains cas.
- Tu dis que si le context est vide, il mettra le champ à blanc, mais dans mon cas exemple, le context contiendrait toujours la dernière valeur rencontrée, non ?

[Sylvain James]

Pour compléter le post de RDM sur le nouveau match :

• Plus besoin de XMLC_Pivot dans le formulaire.
• Possibilité d'imbriquer les Match pour gérer les hiérarchie ORG[1].PSN[1].PSN_FIRST_NAME
• Permet de matcher sur des CommaText (test@test.com;test2@test.com; ). Pratique pour matcher sur un array.join(";") javascript !

Mortel :-)

[RDM]

Excellent, ça sera en effet plus intuitif que le Pivot.
Mais du coup ça me fait penser à 2 choses :
- Est ce que l'itération sera forcément incrémentale numériquement parlant (ITEM[x]... ITEM[x+1] etc.) ? Car jusqu'à maintenant le pivot nous permettait d'itérer quelque soit la valeur de l'indice, et c'était plutôt pratique dans certains cas.

pour ca il faut mettre le MaxRecords pour passer certaines valeurs qui ne serait pas remplies

- Tu dis que si le context est vide, il mettra le champ à blanc, mais dans mon cas exemple, le context contiendrait toujours la dernière valeur rencontrée, non ?

Si ORGANISATION[3].ORG_ID n'existe pas il met ORG_ID à ''
donc l'ancienne valeur de ORG_ID n'est plus dans le context

[Sylvain James]

Merci :-)