ISOTOOLS BUILDER X8 V3.0

Transcription

FICHE VERSION
ISOTOOLS BUILDER X8 V3.0
Nouveautés et évolutions depuis la version 2.2
Sommaire
>> VERSION X8 3.0 BUILD 25 (VERSION CORRECTIVE) _____ 3
A retenir
EVOLUTIONS __________________________________________ 3
CORRECTION __________________________________________ 3
EVOLUTIONS __________________________________________ 3
-- Important -Suppression de la diffusion en ASP. Seule la
diffusion en ASP.Net persiste.
CORRECTIONS _________________________________________ 3
EVOLUTIONS __________________________________________ 4
CORRECTIONS _________________________________________ 5
EVOLUTIONS __________________________________________ 5
CORRECTIONS _________________________________________ 6
EVOLUTIONS __________________________________________ 6
CORRECTIONS _________________________________________ 7
>> VERSION X8 3.0 BUILD 14 (RELEASE) ________________ 7
PASSAGE DE COLLECTION D’OBJETS EN PARAMÈTRE _________ 8
IMAGERIE PRODUIT ____________________________________ 9
INTÉGRATION DE JQUERY ET KENDOUI ____________________ 9
NOUVEAU SYSTÈME DE LANGUE ET GESTION DU REPLI ______ 10
API D’ACCÈS AU REPLI DES LANGUES_________________________10
FONCTION ITL:LOCALE __________________________________11
SORTIE DERNIERE BUILD X8 V3.0 (KERNEL ID 460225) : 06/12/2013 – RÉF. DOC. : 13BUIX8460225RN01
NOUVEAUTES ET EVOLUTIONS ISOTOOLS STUDIO X8 V3.0
PAGE 2
OUVERTURES LIÉES À SOCOLISSIMO __________________________________________________________________13
MODIFICATION DE L’AUTHENTIFICATION BOUTIQUE SUITE À REFONTE USERS / XRM
(PROCESSUS DE COMMANDE B2C) ___________________________________________________________________15
EVOLUTIONS MINEURES ___________________________________________________________________________16
APPLICATION ___________________________________________________________________________________
ITL__________________________________________________________________________________________
SYNCHRONISATION _______________________________________________________________________________
WIZARD ______________________________________________________________________________________
16
16
17
17
CORRECTIONS ____________________________________________________________________________________17
>> Version X8 3.0 build 25 (version corrective)
ITL Library 2.8.9 – Kernel ID 460225- Sortie le 06/12/2013
Evolutions

[TFS2071] et [TFS2193] Suppression de l’attribut useYUIMarkup sur sds:buttonBar et ajout de l'attribut
useYUIMarkup sur sds:submitButton.

[TFS2504] Prise en compte du containerSpanClass et ajout d’un span autour du libellé du
sds:linkbutton.

[TFS2537] et [TFS650] Amélioration des performances des Recordset ADO. Le IRecord est désormais
disposable.
Correction

[TFS2502] itl:input de type xrm:filter : balise Label fermée sur l'élément l'ouvrant.

[TFS2518] Erreur javascript si problème dans l'expression de la condition d'utilisation d'une ressource.

[TFS2484] La méthode collection.keys() fait de la concaténation de chaîne au lieu d'utiliser un
stringBuilder provoquant alors de mauvaises performances.

[TFS2554] Bug de compatibilité suite à la refonte de IRecord.
Evolutions

[TFS1478] et [TFS1479] Nouveaux articles dans le wiki concernant la trace :
- Activer les traces dans un site diffusion
- Liste des sources disponibles
- Comment créer une nouvelle source de trace
Corrections

[TFS2209] Correction du problème lors de l'appel à rightsGids dans le contexte d’utilisation de SolR.

PAGE 4
[TFS2148] itl:input de type alb:privateImage sans attribut requiredMeta provoque une exception en
runtime.
ITL Library 2.7.8 à 2.8.2 – Kernel ID 460223- Sortie le 12/08/2013
Aucune modification.
Evolutions

[TFS2018] Nouvel événement onAfterGenerateWebConfig appelé après la génération du fichier
web.config en diffusion et en visualisation.
Les propriétés de l'événement sont les suivantes :
o
o
o
o

document : document site
destination : objet destination
isPreview : booléen indiquant si la génération concerne la visualisation
webConfigPath : chemin de fichier web.config généré
[TFS1959] Il existe désormais dans le module isotools une ressource (iso:currencyUtils) qui apporte les
méthode d'affichage d'un nombre selon un format monétaire défini dans la vue Configurer :
o
o
o
isoCurrencyUtils.toCurrency(amount) : cherche le format monétaire le plus approprié en
fonction de la langue courante
isoCurrencyUtils.toCurrencyByName(amount, formatName) : utilise le format monétaire
dont le nom est formatName
isoCurrencyUtils.toCurrencyByFormat(amount, format) : utilise le format passé en
paramètre. Ce format doit respecter ce qui est fait dans la vue Configurer.

[TFS1991] Possibilité d’utiliser la ressource IoniZip côté runtime afin de pouvoir gérer des fichiers
d’extension.zip.

[TFS2063] Amélioration de l'héritage des évènements : les évènements relatifs à des erreurs héritent
désormais de WebBaseErrorEvent. Usage de WebEventCodes.WebExtendedBase pour la
génération du code des évènements

[TFS2035] Ajout dans le web.config de la section <mailSettings> lorsque l'envoi de mail est
configuré dans la destination.

[TFS1994] Amélioration de l’historique dans la vue Modéliser.

[TFS2011] Possibilité d’appeler des .less en visualisation.
PAGE 5
Corrections

[TFS2032] La fonction sm_getAdditionalFieldsDef qui permet d'ajouter
complémentaires est appelée dans un contexte où "this" n'est pas valide.
des
champs

[TFS1933] Correction de l’erreur 500 suite à l’utilisation d’une même clé dans une collection de
configuration.

[TFS2040] L'usage d'un itl:create en tâche de fond (hors du contexte d'une requête HTTP) produit
une exception.

[TFS2066] Correction de l’erreur dans l’expression SortExpression de omc:stringItem.
Evolutions

[TFS1841] Au niveau de la déclaration d'une classe, on peut désormais définir des indexes de base
de donnée (en plus de ceux créés implicitement par le modèle : association, clé primaire... etc).

[TFS1845] Les dll compilées par ITLLibrary peuvent désormais définir la trace.

[TFS1851] Amélioration des performances dans le contexte de la synchronisation par l’ajout d’un
index sur la notion de clé de synchronisation.

[TFS1852] Amélioration des performances des requêtes OCS par l’ajout d'un index sur
ocs_card.ocsStatus.

[TFS1860] Amélioration du Dispose de EC et des IsoPage.

[TFS1863] Ajout de l’élément itl:cache (cache de markup).

[TFS1869] Amélioration de la modularité par le déplacement de la chaîne de connexion à
ADO.Net à la base de données vers le fichier web.config.

[TFS1907] L'attribut restrictAllToVisible dde <sds:table-selection> est obligatoire.
PAGE 6
Attention ! Rupture de compatibilité :
Les éléments <sds:table-selection> doivent être muni explicitement de l'attribut restrictAllToVisible.

[TFS1924] Amélioration des performances de la base : possibilité d'ajouter des indexes à une
structure personnalisée.

[TFS1931] Ajout de l'attribut rel sur itl:link.

[TFS1944] Les urls utilisées pour invoquer les ressources Js ou css contiennent maintenant une
information de version dont le seul rôle est de changer à la livraison d'un nouveau Studio ou d'une
nouvelle extension. Ceci permet alors à chaque navigateur de considérer que la version de la
ressource qu'il connait n'est plus à jour lors du changement de version. On évite ainsi les problèmes
d'erreur javascript liés au fait que les navigateurs utilisaient une version précédente d'une ressource
stockée dans son cache alors que le site met à disposition la nouvelle version.
Corrections

[TFS1915] MatchOid ne peut être utilisé dans une collection mise en variable.

[TFS1938] itl:set sur un booléen génère du SQL invalide.
Evolutions

[TFS1473] Indication de la date de processing (DateTime.Now) dans le méta http-equiv « Date ».
Cette information permettra alors de pouvoir vérifier le fonctionnement du cache simplement en
examinant les retours http (460216).

[TFS1596] Amélioration du dumpOverloadedAttributes de gshp (460218).

[TFS1677] Possibilité de surcharger par le projet/décor des formules récupérant les données (label,
label2, introduction, description et body) de gshp:product (460218).

[TFS1750] Ajout du monitoring des évènements start et end de l'application web (460218).

[TFS1824] Mise en place d'évènement custom de monitoring pour les synchronisations (460220).

[TFS1825] Instrumentation de la trace dans SynchroService avec l’ajout de la nouvelle TraceSource
Isotools.SynchroService.
PAGE 7
Corrections

[TFS1347] Correction de la perte du séparateur lorsqu'on utilise une virgule sur un itl:input de type
iso:decimal (460216).

[TFS1507] Correction de l’erreur en backoffice OCS lorsqu’on utilise
odf:referencesField et que plus de 10 références sont sélectionnées (460216).

[TFS1509] Correction du problème sur un use-distinct avec des ascendingBy / descendingBy depuis
la disponibilité du passage de collection en paramètre (460216).

[TFS1548] Correction du dysfonctionnement de l’itl:mailAttachment (460216).

[TFS1656] Correction du problème de génération de la clause OrderBy si l’ascendingBy n’est pas
porté directement par la collection principale mais par une collection avant association (460216).

[TFS1681] Utilisation de variables globales pour pallier au dysfonctionnement de functionExists avec
les fonctions ajax (460218).

[TFS1758] Les collections passée en paramètre perdent les tri nécessaires aux itl:group.

[TFS1800] Rétablissement du tri dans itl:option (460219).

[TFS1743] Correction de l’erreur dans le backoffice boutique lors de l'activation des traces (460218).

[TFS1774] Correction de l’erreur de typage ITL suite au rechargement
ITLLibrary 2.7.2).

[TFS1811] Clause orderBy mal générée dans le cas d'itl:group sur un critère statique (460220).

[TFS1815] itl:mailAttachment ne fonctionne pas si on lui passe directement une collection en
paramètre.

[TFS1816] Inclure un itl:mailAttachment dans un itl:for-each ne fonctionne pas.

[TFS1840] Correction du problème de destinataire en copie (itl:mailRecipient) sur itl:mail (460220).

[TFS1781] Duplication de la fonction context.codes.usr.registerClassFactory dans les fichiers
method.js et anonymousIdent.js afin que le chargement de ces fichiers Studio script se fasse dans
le bon ordre (460220).

[TFS1864] Ajout de la référence à adodb.dll dans ItlLibrary (460220).
le
composant
du périmètre (460218 –
>> Version X8 3.0 build 14 (Release)
PAGE 8
Attention !
Les noms des extensions produits s’enrichissent désormais des 4 premiers chiffres du kernel ID de la version
avec laquelle elles sont compatibles (le numéro de build n’est donc pas concerné). Le gestionnaire
d’extensions permet l’installation des anciennes versions mais des risques de dysfonctionnement sont
toutefois possibles.
Nous vous conseillons de vous rapprocher de votre revendeur pour en valider le bon fonctionnement.
Passage de collection d’objets en paramètre
Il est maintenant possible de passer des collections d'objets ITL en paramètre. Pour déclarer un paramètre
de type collection, il convient d'écrire :
<itl:page-param name="products" type="collection:gshp:product"/>
Le paramètre peut alors être consommé comme n'importe quelle collection et on peut, en particulier,
l'utiliser dans un énumérateur. Cela permet de pouvoir modulariser entre différentes pages origines. Elles
produiront une collection d'un même type qui sera passée en paramètre à une page assurant le rendu de
ces collections. La page finale pourra donc consommer, dans le même énumérateur, des collections de
même type mais d'origine très diverses.
Il est important de bien comprendre la manière utilisée pour implémenter cet usage. Tout énumérateur ITL
utilise maintenant non pas une requête SQL mais deux requêtes :

La première requête détermine la collection énumérée avec ses critères de tri. Elle est produite
exclusivement avec le select de l'élément <itl:for-each>.

La deuxième requête détermine l'extraction de donnée consommée par l'énumération. Elle est
produite sans utiliser le select du <ilt:for-each> mais utilise toutes les consommations de données
faites à partir des expressions ITL dérivées de la variable de l'itération.
Le runtime ITL va donc fusionner ces deux requêtes. La requête d'énumération est utilisée comme base de
la requête produite dans laquelle est injectée, par une jointure interne, la requête exprimant la collection à
afficher.
Logiquement, une collection passée en paramètre revient à passer une requête SQL exprimant cette
collection.
Pour des raisons de sécurité et de taille, la requête SQL n'est pas passée directement en tant que
paramètre HTTP. On utilise la classe de session ITL de nom iso:sessionData pour faire persister la collection
de manière linéarisée dans une propriété mémo de cette classe.
PAGE 9
L'oid (privé pour la session utilisateur) de l'objet ITL de type iso:sessionData permet de retrouver la collection
initiale lorsque celle-ci sera consommée dans la page. Il est alors utilisé comme paramètre HTTP.
La méthode collection.saveToSession() peut être explicitement appelée pour sauver la collection et
récupérer cet identifiant.
La classe de session ITL iso:sessionData est automatiquement nettoyée à la fin de la session de l'utilisateur.
L'opérateur de choix ?: supporte maintenant le type collection.
Attention ! Rupture de compatibilité :
La sémantique de la propriété « sort » de l’élément ITL <sds:column> a légèrement changée. Cet attribut
contient normalement une expression ITL dans laquelle on définit le critère de tri lié à l’énumérateur.
Il existe deux manières de spécifier le tri par rapport à un champ :
1.
La manière explicite en précisant le nom de l’énumérateur : product.label
2.
La manière implicite en ne le précisant pas : label
Si le nom de l’énumérateur porte le nom d’un champ qu’on veut trier, la forme raccourci qui fonctionnait dans la
version précédente ne fonctionnera plus à cause de l’ambiguïté entre le nom de l’énumérateur et le nom du
champ.
Pour éviter ce problème, il convient de renommer l’énumérateur.
Imagerie produit
Révision des icônes et splash de démarrage de l’application.
Intégration de Jquery et kendoUI
Un élément ressource javascript peut désormais indiquer qu'il nécessite jQuery, jQueryTools, knockout ou
kendoUI. Ceci via les éléments Utilisation de jQuery, Utilisation de jQueryTools, Utilisation de Knowkout,
Utilisation de kendoUI. Cela induit l'insertion d'une balise <script> faisant référence au fichier jquery.min.js
(pour jQuery), jquery.tools.min.js (pour jQueryTools), knockout-min.js (pour knockout) et kendo.all.min.js
(pour kendoUI).
Dans le cas de kendoUI, les feuilles de style CSS kendo.common.min.css, kendo.[theme].min.css,
kendo.dataviz.min.css et kendo.mobile.all.min.css sont aussi référencées dans la page via une balise <link>.
La notion de theme de kendoUI est configurable via le décor en définissant une surcharge de
Configuration de kendoUI.
Par défaut, les URL de bases font références aux CDN :

jQuery :



o
http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/
o
https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/
PAGE 10
jQueryTools:
o
http://cdn.jquerytools.org/1.2.7/all/
o
https://cdn.jquerytools.org/1.2.7/all/
knockout:
o
http://cdnjs.cloudflare.com/ajax/libs/knockout/2.1.0/
o
https://cdnjs.cloudflare.com/ajax/libs/knockout/2.1.0/
kendoUI:
o
http://cdn.kendostatic.com/2012.1.515/
o
https://da7xgjtj801h2.cloudfront.net/2012.1.515/
En visualisation, le système utilise une version embarquée des framework (cela permet le fonctionnement
en mode déconnecté).
Pour l'utilisateur (configurateur, chef de projet) d’Isotools Studio X8 :
Dans un contexte où les CDN par défaut ne sont pas disponibles par les utilisateurs du site (cas d'un intranet
dans un contexte très limitatif), on peut indiquer d'autres URL de base via l'élément Configuration des
framework externes dans l'écosystème technologique.
En outre, le nouvel élément <itl:ko-block data-bind="foreach : items">...</itl:ko-block> permet d'entourer un
contenu par deux commentaires à l'usage de knockout JS. Ceci permet d'utiliser le contrôle de flot
knockout (foreach, if, with) en utilisant des commentaires XHTML. Cela évite d'avoir à utiliser du markup
XHTML pour porter le binding, ce qui n'est pas toujours possible.
Nouveau système de langue et gestion du repli
API d’accès au repli des langues
Avec la nouvelle gestion des langues, une API permet d’accéder à l'information de repli des langues :

Dans le runtime C# : fonction statique
IsoGlobalizationManager.getFallbackForLang(string langId) qui renvoie l'information sous forme de
chaine.

Dans le runtime js : fonction dans isoRuntime.js
getFallbackForLang(langId) qui renvoie l'information sous forme de chaine.
PAGE 11
Fonction itl:locale
Le compilateur ITL a été modifié pour tenir compte de la nouvelle sémantique de repli des langues.
Pour mémoire, le repli de langues au niveau de la base de données se faisait en prenant d'abord la valeur
de la variable localisée dans la langue courante et à défaut la valeur de la variable dans la première
langue du site.
Dans cette release, nous disposons maintenant du contrôle explicite des replis des langues.
Ce repli est paramétrable dans la vue Configurer et induit pour chaque langue du site deux cascades de
langues. Une cascade de langue est la liste des langues considérées pour traduire une ressource pour une
langue donnée. Le processus de traduction va considérer successivement toutes les langues de la
cascade pour trouver une valeur non nulle correspondant à la traduction

La première cascade est utilisée pour traduire les ressources linguistiques issues d’Isotools Studio X8.

La seconde cascade indique les variations linguistiques des colonnes utilisées dans la base de
données.
Le compilateur contient actuellement deux méthodes pour gérer cette notion de repli au niveau des
objets ITL :

La méthode obj.locale('fieldName', [alternativeLang]) actuellement retourne la valeur du champ
fieldName de l'objet obj dans la langue courante. A défaut, elle retourne la valeur dans la langue
alternative qui, si elle n'est pas précisée, sera la première langue du site.

La méthode obj.mainLocale('fieldName') retourne la valeur du champ dans la première langue du
site.
La sémantique de la première méthode évolue pour tenir compte de la liste de langue de repli qui n'est
plus. Plutôt que de ne considérer qu'une liste de deux langues, langue courante et langue alternative
(explicite ou première langue du site), nous considérons maintenant toute la cascade de langues
associées à la langue courante. Si le paramètre de langue alternative est fourni, on ajoute cette langue en
deuxième position de la liste.
Nous n'avons rien changé à la sémantique de la méthode mainLocale qui retourne toujours la traduction
dans la langue principale du site. Elle est simplement maintenant considérée comme obsolète.
Elle est principalement utilisée pour spécifier des champs calculés gérant le repli dans des expressions de la
forme (ghsp:product.effectiveLocalizedLabel) :
onlineAddOn.label || label || onlineAddOn.mainLocale('label') || mainLocale('label')
On remarquera au passage que cette expression est différente de :
onlineAddOn.locale("label") || locale("label")
PAGE 12
dont la valeur équivaut à :
onlineAddOn.label || onlineAddOn.mainLocale('label') || label || mainLocale('label')
C'est pour cette raison que le repli automatique des champs localisés n'existe pas dans ITL.
Pour adapter ces macros de repli au nouveau modèle de repli multi langues, nous avons introduit la
fonction ITL getBestLocale.
getBestLocale(<champ localisé 1>, <champ localisé 2>[, lang])
Les deux premiers paramètres sont des expressions identifiant deux champs localisés.
Le dernier paramètre (lang) est la langue de traduction désirée avec comme défaut la langue courante.
Cette fonction va renvoyer la meilleure traduction issue des deux champs localisés en donnant une priorité
au premier champ.
Pour ce faire, la fonction étudie la cascade de langue pour la base de données et pour chacune des
langues, considère successivement pour chacune des deux expressions l'existence d'une valeur. La
fonction va retourner la première valeur non nulle.
Cette fonction permet donc de gérer à la fois un repli applicatif (tel que la surcharge d'un champ par un
autre) entre deux expressions localisées avec le repli linguistique.
Avec cette fonction, la précédence est donnée d'abord aux langues puis à la surcharge.
Si la cascade de langues est "en" puis "fr", l'appel de :
getBestLocale(obj.a, obj.b)
est équivalente à :
a || b || obj.get("a", "fr") || obj.get("a", "fr")
Ce qui signifie qu'on ne donnera une valeur dans la langue alternative que si aucune valeur n'est trouvée
dans la langue courante.
Cette fonction est maintenant utilisée dans les macros de repli en remplacement de l'appel à la méthode
obsolète mainLocale.
Enfin une nouvelle méthode est ajoutée aux objets et énumérateurs ITL :
obj.translateField('fieldName' [, lang])
Cette méthode traduit le champ localisé fieldName de l'objet dans la langue lang (à défaut la langue
courante) en considérant la cascade de langues de la base de données de cette langue.
PAGE 13
La fonction ITL getLanguages retourne une liste d'objets de type Language décrivant la langue avec son
nom, son libellé et le booléen isSiteLanguage qui indique si cette langue est la langue courante.
Cette fonction se limite à lister les langues du site.
La nouvelle fonction getDatabaseLanguages retourne la liste des descriptions des langues utilisées par la
base de données. On trouvera parmi elles les langues du site.
Ouvertures liées à SoColissimo
Plusieurs ouvertures liées au développement de la fonction Socolissimo ont été réalisées. Elles permettent
de gérer facilement un autre service de livraison si besoin :

Ajout de l’élément Configuration des services de livraison qui accepte tout élément ayant
l’interface
gshpShippingServiceConfig
dans
sa
définition
(voir
l’élément
soColissimoShippingServiceConfig du module e-shopLaPoste),

L’élément Zone de livraison dispose désormais d’une case à cocher Nécessite un service de
livraison et d’une liste de choix proposant tous les services de livraison définis dans la vue
Configurer,

Le template gshp:showBasketOption a été créé sur la classe gshp:shippingZone. Il redirige selon la
zone choisie (donc selon l’utilisation d’un service de livraison) vers l’appel de l’ancien template
gshp:showBasketOption de gshp :carrier ou vers le template xsl gshp:showBasketCarrierOption du
service de livraison associé à la zone(Voir feuille de style xls dans le module e-shopLaPoste),

Dans le template basketDisplayStep4.xml , appel du template ci-dessous et ajout d’un nouveau
champ caché shippingServiceDescr destiné à être utilisé par le service pour son besoin et passé à
l’étape suivante du processus,

En base, la classe gshp :command possède les 3 nouveaux champs shippingServiceUser,
shippingServiceType et shippingServiceDescr
o
shippingServiceUsed doit contenir le iso:gid de l’élément de configuration utilisé,
o
shippingServiceType doit contenir le nom xml complet de l’élément de configuration
utilisé,
o
shippingServiceDescr doit contenir la chaine de description de la livraison,
o
Il est impératif que la description rappelle le type du service.
Exemple :
Pour SoColissimo, la chaîne est de la forme nom:valeur avec | comme séparateur
configType:laposte:soColissimoShippingServiceConfig
configGId:
weight:
type:
PAGE 14
modeLabel:
// Type de la configuration et description
// Gid du service de livraison SoColissimo définie dans le Studio
// Poids en gramme de la commande
// Type de livraison (deliveryAtHome,
deliveryAtHomeWithoutSignature, deliveryAtHomeWithAppointment
ou deliveryPoint)
// Mode de livraison (home, homeWithoutSignature,
homeWithAppointment, shop, cityssimo ou postOffice)
// Libellé du mode de livraison
Point de retrait (FACULTATIF)
dlvyPtId:
dlvyPtType:
// Identification SoColissimo du point de retrait
// Type SoColissimo du point de retrait (A2P, CIT, BPR, CDI ou ACP)
Prix
price:
vatPrice:
sPrice:
sVatPrice:
codeERP:
// Prix HT (double)
// Prix TTC (double)
// Prix HT et devise (string)
// Prix TTC et devise (string)
// Code ERP identifiant la livraison
Adresse
addrName:
civilityCode:
civility:
firstName:
lastName:
adr1:
adr2:
adr3:
zip:
city:
countryCode:
country:
// Nom du lieu de livraison (Bureau de poste, magasin, ...)
// Code de la civilité
// Libellé de la civilité
// Prénom
// Nom
// Adresse 1 du lieu de livraison (domicile ou point de retrait)
// Adresse 2
// Adresse 3
// Code postal
// Ville
// Code du pays
// Libellé du pays
Instructions pour la livraison à domicile (FACULTATIF)
doorCode1:
doorCode2:
instructionsCompl:
// Code de la porte 1
// Code de la porte 2
// Instructions complémentaires
Notification (FACULTATIF)
notifEmail:
notifPhone:
// Email de notification
// Téléphone de notification
mode:
Attention ! Il est du ressort du service concerné de modifier en base ces 3 champs de la commande après
validation du mode de livraison. Il en est de même pour l’adresse de livraison.
Pour déclencher une modification de la commande et de l’adresse de livraison, le template
basketProcessorStep5.xml détecte éventuellement l’utilisation d’un service de livraison et appelle alors le
template xsl gshp:updateCommandByShippingService.
Exemple : Avec SoColissimo, le paramètre de page shippingServiceDescr est récupéré dans le template
en question du service dans le but d’être décortiqué par une classe C# et de mettre à jour les champs en
base shippingServiceUser, shippingServiceType et shippingServiceDescr de la commande en cours ainsi
que l’adresse de livraison.
PAGE 15
Dans les pages Mode de paiement ou Récap de la commande, on rappelait déjà le transporteur utilisé et
le prix du port. Mais dans le cas d’un service de livraison, il peut être important de rajouter certaines
informations importantes.
Pour cela, les templates gshp-paymentItem-showShippingMode.xml et gshp-commandItemshowShippingMode.xml utilisés respectivement dans les pages mentionnées ci-dessus appellent
respectivement
les
templates
xsl
gshp:showPaymentItemShippingMode
et
gshp:showCommandItemShippingMode pour afficher les infos de livraison.
Exemple : Avec SoColissimo, on effectue un rendu classique « Icône, libellé du transporteur et prix » mais en
plus, un objet C# charge la description contenue dans le champ shippingServiceDescr de la commande
et fournit au template des informations complémentaires (mode de livraison, code d’accès, …). (voir
generic-laposte_showSoColissimoCommandItemShippingMode.xml).
Modification de l’authentification boutique suite à refonte Users / XRM (processus
de commande B2C)
Avant de lire ce qui suit, veuillez consulter le document Release_notes_ext_XRMServer_V4.17.pdf associé à
la release 3.0 pour connaitre les évolutions concernant l'authentification et les fonctions de
MembershipUtils.
Suite à la nouvelle gestion de l'authentification, il est impératif de recharger une page du site pour que
l'authentification soit effective et le profil rechargé.
Il est possible de spécifier la page de redirection appelée après l'authentification en initialisant le
paramètre de requête returnURL.
A l'étape 2 du processus de commande B to C, les formulaires permettent de :

s'authentifier (formulaire d'authentification avec cmd à 'login' et step à 2)

créer un nouveau compte Client/Utilisateur (formulaire d'édition avec cmd à 'newClient' et step à
3)

éditer le client déjà loggué (formulaire d'édition avec cmd à 'editClient' et step à 3)
Attention ! Si le template basketDisplayStep2.xml a été surchargé ou si les templates du décor teste le
cmd, il faut bien comprendre que le paramètre cmd du 2e formulaire avait auparavant la valeur
'identification'. Maintenant, il peut désormais avoir la valeur 'newClient' ou 'editClient'.
De plus, si le template basketDisplayStep2.xml avait été surchargé par le décor, il faut aussi rajouter les
paramètres returnURL.
En standard, les formulaires appellent la page Panier et au chargement de celle-ci :

si cmd = 'login', l'authentification est demandée (Cf autoLog)
PAGE 16

si cmd = 'newClient', la création du compte est effectuée dans le basketProcessorStep3 et
l'authentification demandée ultérieurement (Cf authenticateCreatedUserAccount)

si cmd = 'editClient', la mise à jour du compte est effectuée dans le basketProcessorStep3 suivi du
rendu de l'étape 3
Attention ! Les fonctions autoLog et authenticateCreatedUserAccount de gshp.UserManager appellent la
fonction signIn en précisant que la redirection doit être immédiate (paramètre endResponse à true).
Pour cette raison, l'authentification qui suit la création d'un nouveau compte n'est plus faite dans le
basketProcessor mais entre les templates basketProcessor (PreProcessor, Processor et PostProcessor) et les
template basketDisplay (PreDisplay, Display et PostDisplay) (Cf basket.xml). Le traitement spécifique du
décor est donc exécuté avant la redirection !
L'appel de autoLog reste aussi en début de template basket.xml.
La redirection immédiate effectuée après les 2 authentifications tient compte du paramètre returnURL. Ce
paramètre est initialisé par les 2 formulaires mais dans le cas d'une création de compte, il faut revenir sur la
même page en spécifiant l'oid du client. Pour cette raison, comme l'oid est encore inconnu au moment de
l'envoi du formulaire, on fait un setRequestVar('returnURL', returnUrlParams) juste après la création des
comptes client/utilisateur (basketProcessorStep3.xml).
returnURL est la nouvelle url de redirection avec les paramètres step (3), cmd ('' pour ne pas recréer/éditer
le nouveau compte), client (oid du nouveau compte), canInvoiceElsewhere et canShipElsewhere (valeur
des cases à cocher de nouvelles adresses).
Concernant les paramètres can....Elsewhere, ils sont remis dans l'url de redirection car ils ne sont pas utilisés
par les templates de traitement (contrairement aux champs d'édition) mais par le templates de rendu de
l'étape 3. N'étant pas stockés en base ni utilisés avant la redirection, il est impératif de les renvoyer.
Si le décor a rajouté de nouveaux champs dans le formulaire et en fonction de leur usage (traitement ou
affichage), le décor devra éventuellement faire son propre setRequestVar dans le template surchargé
basketPostProcessor.xml en rajoutant les paramètres d'url manquants.
Evolutions mineures
Application
[TFS750] Ouverture au niveau des fichiers studioScript pour permettre de rajouter une association sur les
classes complémentaires.
ITL

[TFS756] Gestion de l’attribut readonly dans un itl:option.

PAGE 17
[TFS1282] Nouvel élément <itl:simple-comment content="text éventuellement calculable"/>
permettant de produire un commentaire XHTML donc le contenu est défini par content. Il convient
d'utiliser les {} si le contenu est calculé par une expression ITL.
Synchronisation
[TFS1067] Les méthodes suivantes utilisées par la classe GenericRpcServerDownload de ItlRuntime
(synchronisation remontante) sont devenues statiques :

getSqlExpIfThenElse,

getSqlExpConcat,

getSqlExpConcatNonNullWithSep,

getSqlExpConcatWithSep

protectText
Ainsi que les méthodes suivantes de gshp.Downloader :

getSqlExpRowDiscountAmount,

getSqlExpRowDiscountVatAmount,

getSqlExpTotalPrice

getSqlExpTotalVatPrice
[TFS1291] La ressource omc:objectModelConfig générant le fichier objectModelData.config ne doit
désormais plus être utilisée. Préférée lui la ressource omc:xmlObjectModelConfig qui génèrera alors le
fichier objectModel.xml.
Wizard
[TFS1140] Il est désormais possible dans les assignations d'écran d'assistant de spécifier une expression à
évaluer en la préfixant de "javascript:" (voir dans le module aspx l'écran webServiceProtection, assignation
de httpURLAdmin).
Corrections

[X8-4405] Correction du problème de fermeture de variable dans itl:for.

[X8-4444] Correction de l’erreur 500 apparaissant lorsque l’utilisateur commence sa session via une
page contenue dans un sous-répertoire et non pas à la racine du site.
PAGE 18

[X8-4574] Suite aux erreurs d’exécution liées à la disparition de setSessionOid, un itl:using a été créé
tel que <itl:using name="sessionContext" select="new SessionContext(session)">

[TFS306] Correction d'un bug faisant qu'un contrôle ajax:reference ou ajax:references ne
fonctionnait pas dans une page construite à partir d'un modèle de page nommé.

[TFS449] Désormais lorsqu'un module projet est spécifié (racine de l'élément "Configuration des
modèles"), celui-ci est bien considéré dans le périmètre du site (les ressources qu'il définies sont
accessibles) sans avoir besoin d'une autre référence explicite.

[TFS524] Correction de l’erreur de parsing par JSON d’une chaîne avec ‘ et ayant subi une syntax
= « jstring ».

[TFS481] Correction du problème de chaînes longues ayant plusieurs caractères ‘’

[TFS676] La fonction Integer(double) utilise maintenant un arrondi par défaut au lieu d'un arrondi
au plus près, pour coller aux standards usuels de conversion de type.

ISOTOOLS BUILDER X8 V3.0

Transcription

Documents pareils

COTE AUTO Asiles-colis

CA M`INTERESSE Postal

1er choix - Les Arvernes Suisses

CATALOGUE MOTO ACCESSOIRES 2016 /// CHARTES D

pare-brise “airflow” scooter

TELE 2 SEMAINES Email

DUCATI PANIGALE 1199 12-14 DUCATI MONSTER 1200 14

SUZUKI BURGMAN 200 14-16 SUZUKI GW250/GW250F 15

Télécharger le document PDF

L`éditeur de logiciels SPRING Technologies échange deux