HCL Commerce Infrastructure AJAX

L'infrastructure AJAX HCL Commerce est une extension de l'infrastructure jQuery AJAX. Elle fournit un cadre simple d'emploi, qui répond à la plupart des besoins AJAX en matière de développement de sites marchands tout en masquant certaines parties de code répétitives et complexes auxquelles le développeur est souvent confronté.

Quatre scénarios courants sont impliqués avec l'infrastructure AJAX HCL Commerce :

  1. Un appel AJAX est exécuté sur le Transaction server pour mettre à jour un objet métier. Des sections de la page sont actualisées avec un nouveau contenu si la mise à jour réussit. Le nouveau contenu est extrait en utilisant les appels AJAX suivants sur le Transaction server.
  2. Un appel AJAX est émis pour actualiser une section de la page du fait de certaines interactions avec le client.
  3. Un appel AJAX est exécuté sur le Transaction server pour mettre à jour un objet métier. Des sections de la page doivent être actualisées avec le nouveau contenu si la mise à jour réussit. Le nouveau contenu est extrait en utilisant les appels AJAX suivants sur le Transaction server. La procédure est identique à celle du premier scénario, mais au lieu que le code soit modulaire, une approche pesant moins sur le trafic sur le serveur est nécessaire.

    Dans ce scénario, un appel AJAX est exécuté sur le serveur HCL Commerce pour mettre à jour un objet métier. Des sections de la page sont actualisées avec un nouveau contenu si la mise à jour réussit. Toutes les informations nécessaires à l'actualisation du contenu de la page sont renvoyées sous forme d'objet JSON. Le client dispose alors du contenu de l'objet JSON et utilise l'API de manipulation DOM pour modifier toutes les zones de la page qui doivent être modifiées du fait de la mise à jour réussie.

  4. Un appel AJAX est exécuté sur le Transaction server et les données JSON sont demandées. Des sections de la page sont ensuite mises à jour à l'aide de JavaScript et de l'API de manipulation DOM.

L'infrastructure AJAX HCL Commerce n'est pas nécessaire pour le troisième et le quatrième scénario, car ces scénarios peuvent être exécutés directement en utilisant l'API jQuery AJAX.

Important : Evitez d'effectuer des appels AJAX simultanés pour des commandes. En particulier, évitez les appels simultanés qui transforment un utilisateur générique en nouvel utilisateur invité avec un jeton d'activité d'utilisateur. Les appels simultanés se traduisent par plusieurs jetons d'activité d'utilisateur, ce qui entraîne des résultats indésirables.

Vous pouvez effectuer des appels AJAX simultanés pour des vues.

Scénario 1 : Mise à jour d'un objet métier dans HCL Commerce à l'aide d'AJAX, puis actualisation de différentes zones en utilisant les demandes AJAX suivantes pour obtenir les contenus actualisés

Ce scénario comprend deux parties :
  1. Un appel AJAX est exécuté dans une commande de contrôleur HCL Commerce ou un service HCL Commerce pour mettre à jour un objet métier (ou plusieurs).
  2. Les demandes get AJAX suivants sont exécutées dans des vues HCL Commerce pour extraire le nouveau contenu HTML de chaque zone en cas de réussite de la mise à jour.
Dans ce scénario, les deux schémas ci-dessous montrent les interactions qui ont lieu entre le client et le serveur HCL Commerce.

Schéma des interactions lorsque vous appelez des commandes du contrôleur HCL Commerce :

Schéma des interactions lorsque vous appelez des commandes de contrôleurHCL Commerce

Schéma des interactions lorsque vous appelez des services HCL Commerce :

Schéma des interactions lorsque vous appelez des servicesHCL Commerce

1. Exécution d'un appel AJAX dans une commande ou un service de contrôleur HCL Commerce

Avant que le client puisse appeler une commande ou un service de contrôleur HCL Commerce en utilisant AJAX, le Transaction server doit définir que la commande ou le service du contrôleur peut être appelé en utilisant AJAX (au lieu du modèle de programmation classique lorsque la demande est effectuée et que l'exécution de HCL Commerce implique une nouvelle redirection).

Pour qu'une commande de contrôleur ou un service soient aptes à recevoir des demandes du type AJAX, définissez simplement une nouvelle entrée d'action Struts dans le fichier XML de configuration Struts. Dans cette entrée, identifiez la commande de contrôleur ou le service en tant qu'action du type AJAX. Par exemple, pour créer une action Struts pour la commande de contrôleur InterestItemAdd qui peut être appelé en utilisant AJAX, elle doit être définie dans le fichier XML de configuration Struts :

Figure 1. Commandes :
<action
  parameter="com.ibm.commerce.interestitems.commands.InterestItemAddCmd"
  path="/AjaxInterestItemAdd"
  type="com.ibm.commerce.struts.AjaxAction">
    <set-property property="authenticate" value="0:0"/>
    <set-property property="https" value="0:1"/>
</action>
<action class="com.ibm.commerce.struts.v2.AjaxAction" name="AjaxInterestItemAdd">
<param name="authenticate">0:0</param>
<param name="https">0:1</param>
<param name="parameter">com.ibm.commerce.interestitems.commands.InterestItemAddCmd</param>
</action>
Figure 2. Services :
<action 
  parameter="order.addOrderItem" 
  path="/AjaxOrderChangeServiceItemAdd" type="com.ibm.commerce.struts.AjaxComponentServiceAction">
    <set-property property="authenticate" value="0:0"/>
    <set-property property="https" value="0:1"/>
</action>
<action class="com.ibm.commerce.struts.v2.AjaxComponentServiceAction" name="AjaxOrderChangeServiceItemAdd">
<param name="authenticate">0:0</param>
<param name="https">0:1</param>
<param name="parameter">order.addOrderItem</param>
</action>
Les caractéristiques d'une URL de type AjaxAction est qu'après l'exécution de la commande ou du service, l'exécution de HCL Commerce transfère automatiquement la demande à l'une des deux vues connues pour composer un objet JSON contenant toutes les entrées de la réponse destinée au client. Les deux vues connues mappent à ces fichiers JSP.
  • WC_eardir/Stores.war/AjaxActionResponse.jsp (cas de réussite)
  • WC_eardir/Stores.war/AjaxActionErrorResponse.jsp (cas d'échec)
  • HCL Commerce Developer workspace_dir/Stores/WebContent/AjaxActionResponse.jsp
  • HCL Commerce Developer workspace_dir/Stores/WebContent/AjaxActionErrorResponse.jsp
Maintenant que les actions Struts AJAX sont définies, l'API wcService.declare est utilisée dans le code JavaScript pour définir un service à associer à chacune des URL requises appelées dans la page. L'API wcService.declare déclare un objet de service JavaScript qui peut appeler des actions Struts de type AJAX dans HCL Commerce. Cela laisse au programme client la liberté de choisir le moment d'exécuter l'appel AJAX. Par exemple, le code JavaScript ci-dessous dans le client définit un objet de service pour appeler InterestItemAdd en utilisant AJAX :
wcService.declare({
  id: "AjaxInterestItemAdd",
  actionId: " AjaxInterestItemAdd",
  url: " AjaxInterestItemAdd",
  formId: "",
successHandler: function(serviceResponse) {
      alert("success");	
    },
failureHandler: function(serviceResponse) {
    if (serviceResponse.errorMessage) {
      alert(serviceResponse.errorMessage);
    }
  } 
});
La définition définit simplement un objet et ne déclenche pas encore l'appel AJAX auprès du serveur HCL Commerce. Pour déclencher l'appel AJAX, l'API suivante est utilisée :

  wcService.invoke("AjaxInterestItemAdd");
La fonction successHandler définie dans la déclaration de service est exécutée et si la demande se termine avec succès, elle publiera un événement avec l'actionId du service. Pour plus d'informations sur les programmes d'écoute d'abonnement et de publication, voir les détails dans wcTopic .

2. Exécution d'appels AJAX dans les vues HCL Commerce pour obtenir un contenu actualisé

L'infrastructure AJAX HCL Commerce fournit un objet JavaScript appelé WCRefreshController. Tout élément HTML d'une page peut être désigné comme zone d'actualisation. Le contenu dans la balise HTML est remplacé par un nouveau contenu provenant du serveur HCL Commerce chaque fois que le contrôleur d'actualisation associé à la zone d'actualisation déclenche la demande d'actualisation. L'exemple de code suivant définit une zone d'actualisation dans la page :

<div wcType="RefreshArea"
   id="WishlistSelect_Widget" 
   declareFunction="declareRefreshArea()"
   refreshurl="<c:out value="${WishListSelectAreaView}"/>">
</div>
Dans l'HTML où la zone d'actualisation est définie, il doit spécifier un attribut wcType avec la valeur "RefreshArea". Il existe également un deuxième attribut obligatoire appelé declareFunction qui indique où le contrôleur d'actualisation est défini dans l'attribut de declareFunction. L'attribut refreshurl définit l'URL du serveur de transactions à appeler pour obtenir le nouveau contenu HTML pour la zone d'actualisation à laquelle le contrôleur d'actualisation est associé. Les contrôleurs d'actualisation sont automatiquement inscrits comme écouteurs des événements modelChanged et renderContextChanged. Par conséquent, lorsque ces événements se produisent, ils en sont avertis. Ils évaluent ensuite les modifications du modèle et/ou du contexte de rendu et déterminent si les zones d'actualisation qu'ils gèrent doivent être actualisées ou non. L'exemple de code suivant montre comment définir un contrôleur d'actualisation :

function declareRefreshArea () {
   var myWidgetObj = $("#WishlistSelect_Widget")
   var myRCProperties = wcRenderContext.getRenderContextProperties("WishlistSelect_Context");
   
   var renderContextChangedHandler = function() {
   };

   // model change
   wcTopic.subscribe(order_updated, function() {
   myWidgetObj.refreshWidget("refresh", myRCProperties);
   });

   // post refresh handler
   var postRefreshHandler = function() {
   };

   // initialize widget with properties
   $("#"+divId).refreshWidget({
      renderContextChangedHandler: renderContextChangedHandler,
      postRefreshHandler: postRefreshHandler
   });

}
La fonction wcTopic.subscribe est exécutée par l'infrastructure AJAX HCL Commerce dès qu'un événement de publication est déclenché par des actions wcService.invoke() réussies. La fonction wcTopic.subscribe écoute les modifications d'un actionid spécifique qui a un intérêt pour la zone d'actualisation. Le widget d'actualisation ("refresh") est le code qui exécute un appel AJAX auprès du Transaction server pour l'URL spécifiée dans le contrôleur d'actualisation. Lorsque le nouveau fragment HTML est renvoyé par le serveur, l'infrastructure détruit tout ce qui existait dans la zone d'actualisation et remplace son contenu par le nouveau fragment HTML.
La fonction postRefreshHandler est une autre fonction utile, car c'est la dernière fonction appelée par l'infrastructure après qu'une zone d'actualisation a été actualisée avec le nouveau contenu. Elle peut servir à débloquer l'interface utilisateur si celle-ci a été bloquée durant les appels AJAX.
Remarque : Si le contexte de rendu n'est pas utilisé, il n'est pas nécessaire de le définir.

Scénario 2 : Actualisation d'une zone de la page à l'aide d'une demande AJAX pour obtenir le contenu actualisé

Les zones de la page doivent être actualisées avec le nouveau contenu lorsque les utilisateurs interagissent avec l'interface utilisateur. Ce scénario utilise l'API de contexte de rendu, de zone et de contrôleurs d'actualisation à partir de l'infrastructure AJAX de HCL Commerce.

Un objet contexte de rendu assure le suivi des informations de contexte du programme client et peut déclencher des événements renderContextChanged chaque fois que l'une quelconque de ses propriétés est mise à jour. Les contrôleurs d'actualisation sont automatiquement inscrits comme écouteurs de tous les événements renderContextChanged. La logique d'un contrôleur d'actualisation détermine si la modification du contexte doit déclencher une mise à jour d'un widget de zone d'actualisation. Par conséquent, dans l'élément renderContextChangedHandler d'un contrôleur d'actualisation, l'API est utilisée pour comparer les propriétés de contexte testForChangedRC afin de déterminer si la propriété de contexte est modifié, puis de déclencher l'actualisation de la zone d'actualisation.

Scénario 3 : Mise à jour d'un objet métier dans HCL Commerce à l'aide d'AJAX et renvoi de toutes les informations de mise à jour pertinentes à l'aide de JSON

Ce scénario peut être obtenu en utilisant directement l'API jQuery. Par conséquent, il n'est pas nécessaire d'utiliser l'infrastructure AJAX de HCL Commerce si ce scénario présente un intérêt pertinent. Le dojo.xhrPost API est utilisé avec le modèle de programmation d'exécution HCL Commerce classique, où une demande est exécutée auprès d'une commande de contrôleur ou d'un service e t après l'exécution, l'exécution de HCL Commerce redirige la demande vers l'élément spécifié dans l'URL ou les paramètres errorViewName dans la demande initiale. Par exemple,
var parameters = {};
  parameters.storeId = storeId;
  parameters.langId=langId;
  parameters.catalogId=catalogId;
  parameters.catentryId=productId;	
  parameters.URL="MiniCartContentsJSON";
parameters.errorViewName="MiniCartContentsJSON";
  $.ajax({
    url: "OrderChangeServiceItemAdd",
    method: "post",				
    dataType: "json",
    data: parameters,
    success: refreshMiniCart,
    error: function(jqXHR,textStatus, err) {
    }
  });
Dans ce fragment de code, une demande AJAX est adressée au service OrderChangeServiceItemAdd, puis redirigée vers la vue MiniCartContentsJSON, laquelle est mappée à un fichier JSP qui crée un objet JSON avec son contenu. Dans ce scénario, l'hypothèse est que le même fichier JSP gère le scénario d'erreur, car errorViewName est défini sur la même vue MiniCartContentsJSON. Le programme client récupère ensuite le contrôle et la fonction load ou error est appelée, selon que l'opération réussit ou échoue.
Remarque : Le scénario d'erreur n'est appelé que lorsqu'il y a des difficultés de communication avec le Transaction server. Autrement, une réussite ou une exception du code HCL Commerce exécute la fonction load. La fonction load détermine, d'après l'objet JSON, si la demande a réussi ou échoué.

La fonction load utilise l'objet JSON et l'API de manipulation DOM pour remplacer tous les éléments dans la page qui doit être mise à jour avec les nouvelles données qui ont entraîné la mise à jour du serveur. Il n'est pas nécessaire d'enregistrer les URL sous AjaxAction, car ce scénario n'utilise pas les nouvelles infrastructures AJAX de HCL Commerce.

Scénario 4 : Appel du Transaction server en utilisant AJAX pour rassembler de nouvelles données comme objet JSON et actualisation du contenu des pages

Ce scénario peut être obtenu en utilisant directement l'API jQuery. Par conséquent, il n'est pas nécessaire d'utiliser l'infrastructure AJAX de HCL Commerce si ce scénario présente un intérêt pertinent. L'API jQuery est utilisée avec le modèle de programmation d'exécution HCL Commerce classique, dans lequel une demande est exécutée dans une vue mappée à un fichier JSP qui crée un objet JSON. Dans la fonction load de l'API AJAX, l'API de manipulation DOM est utilisée pour insérer le contenu JSON dans les éléments de la page Web.