Accueil > Développeurs > Releases notes Builder
 

Releases notes Builder

Release notes Isotools Builder X8 V3.0

Publiée le 17/07/2014 | ID : 13BUIX8460225RN01

A noter !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.

>> 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.

Corrections
  • [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 comptabilité suite à la refonte de IRecord.

 

>> Version X8 3.0 build 24 (version corrective)

ITL Library 2.8.4 – Kernel ID 460224 - Sortie le 17/10/2013

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.

  • [TFS2148] itl:input de type alb:privateImage sans attribut requiredMeta provoque une exception en runtime.

>> Version X8 3.0 build 23 (version corrective)

ITL Library 2.7.8 – Kernel ID 460223- Sortie le 12/08/2013

Aucune modification.

>> Version X8 3.0 build 22 (version corrective)

ITL Library 2.7.7 – Kernel ID 460222- Sortie le 02/08/2013

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 :

    • 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 :

    • 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

Corrections
  • [TFS2032] La fonction sm_getAdditionalFieldsDef qui permet d'ajouter des champs complémentaires est appelée dans un contexte où "this" n'est pas valide.

  • [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.

>> Version X8 3.0 build 21 (version corrective)

ITL Library 2.7.5 – Kernel ID 460221- Sortie le 12/06/2013

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.

    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.

>> Version X8 3.0 build 20 (version corrective)

ITL Library 2.7.4 – Kernel ID 460220- Sortie le 22/04/2013

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.

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 le composant 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  du périmètre (460218 – 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 dasse dans le bon ordre (460220).

  • [TFS1864] Ajout de la référence à adodb.dll dans ItlLibrary (460220).

>> Version 3.0 build 14 - kernel ID 460214 (Release)

ITL Library 2.6.5 - Sortie le 07/11/2012

Nouveautés
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.

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 :

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.

 

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")

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.

 

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é

    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

// Type de la configuration et description

 configGId:

 // Gid du service de livraison SoColissimo définie dans le Studio

 weight: 

 // Poids en gramme de la commande

 type:

 // Type de livraison (deliveryAtHome, deliveryAtHomeWithoutSignature, deliveryAtHomeWithAppointment ou deliveryPoint)

 mode:

 // Mode de livraison (home, homeWithoutSignature, homeWithAppointment, shop, cityssimo ou postOffice)

 modeLabel:

 // Libellé du mode de livraison

 

 

Point de retrait (FACULTATIF)

 

 dlvyPtId:

 // Identification SoColissimo du point de retrait

 dlvyPtType:

 // Type SoColissimo du point de retrait (A2P, CIT, BPR, CDI ou ACP)

 

 

Prix

 

 price:

 // Prix HT (double)

 vatPrice:

 // Prix TTC (double)

 sPrice:

 // Prix HT et devise (string)

 sVatPrice:

 // Prix TTC et devise (string)

 codeERP:

 // Code ERP identifiant la livraison

 

 

Adresse

 

 addrName:

 // Nom du lieu de livraison (Bureau de poste, magasin, ...)

 civilityCode:

 // Code de la civilité

 civility:

 // Libellé de la civilité

 firstName:

 // Prénom

 lastName:

 // Nom

 adr1:

 // Adresse 1 du lieu de livraison (domicile ou point de retrait)

 adr2:

 // Adresse 2

 adr3:

 // Adresse 3

 zip:

 // Code postal

 city:

 // Ville

 countryCode:

 // Code du pays

 country:

 // Libellé du pays

 

 

Instructions pour la livraison à domicile (FACULTATIF)

 

 doorCode1:

 // Code de la porte 1

 doorCode2:

 // Code de la porte 2

 instructionsCompl:

 // Instructions complémentaires

 

 

Notification (FACULTATIF)

 

 notifEmail:

 // Email de notification

 notifPhone:

 // Téléphone de notification

 

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.

 

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-commandItem-showShippingMode.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)

  • 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.

  • [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.

  • [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.