La solution XiConnect est un serveur d’échange intermédiaire entre un site Magento et un ERP, ce qui permet de synchroniser les données entre ces deux entités sans nuire aux performances du site eCommerce.

Chaque flux de données (produits, commandes, stocks…) passant entre l’ERP et Magento via XiConnect est matérialisé par un ou plusieurs fichiers CSV.
L’ERP et Magento possèdent des API d’import/export capables de créer et consommer ces fichiers.

Schema des flux entre Magento et un ERP

XiConnect possède une base de données où ces échanges sont répertoriés sous forme d’objets Task, ou tâches. Chaque tâche est caractérisée entre autres par un type d’entité (client, produit, commande…), un sens (de l’ERP vers le site eCommerce ou inversement), son état (actuel et précédent) et son contenu (fichiers concernés).

Un composant de XiConnect, le Task Manager, manipule les tâches, met à jour leur état et lance les traitements nécessaires pour appliquer les règles métier aux flux.

En consultant la base de données, un utilisateur peut à tout moment connaître l’état de chaque flux.

Les screenshots valent mieux qu’un long discours, vous noterez que le css n’est pas sans rappeler une certaine plateforme eCommerce, permettant à nos utilisateurs d’y être familier.

1 – Connexion

Authentification

2 – Gestion des tâches

La page de gestion des tâches est utilisée pour consulter les tâches répertoriées dans la base de données du serveur d’échange, que ce soit les tâches terminées ou les tâches en cours d’exécution.

Elle permet également de donner l’ordre au serveur d’échange de relancer les tâches qui ont échoué.

Affichage des tâches

En double-cliquant sur une tâche, une pop-up apparaît avec, en plus des informations de base sur la tâche, l’emplacement courant du ou des fichiers CSV représentant le flux de données. Si un fichier se trouve sur le serveur d’échange, son chemin est également affiché.

Dans le cas où la tâche en question est une tâche échouée, la pop-up comporte un bouton permettant de la redémarrer.

Détails d'une tâche

3 – Consultation de la base intermédiaire

La page de consultation de la base intermédiaire permet de consulter toutes les tables de la base de données du serveur d’échange. Elle peut être accédée en cliquant sur l’onglet « Base intermédiaire » dans la barre de navigation.

Consultation des données stockées par XiConnect

4 – Gestion des utilisateurs
La page de gestion des utilisateurs permet de visualiser, créer, modifier et supprimer les utilisateurs enregistrés. Elle peut être accédée en cliquant sur l’onglet « Utilisateurs » dans la barre de navigation.

Création / Modification d'un utilisateur

5 – Configuration de XiConnect
La page de configuration du serveur d’échange permet de visualiser et modifier les fichiers de configuration du serveur d’échange, plusieurs configurations sont possibles : «production », «développement », «recette», «intégration»

Elle peut être accédée en cliquant sur l’onglet « Configuration du serveur » dans la barre de navigation.

6 – Configuration de l’adaptateur ERP

Cette page permet de visualiser et modifier le fichier de configuration de l’adaptateur ERP.Elle peut être accédée en cliquant sur l’onglet « Configuration de l’adaptateur » dans la barre de navigation.

Les détails des parties “Configuration du serveur d’échange” et “Configuration de l’adaptateur ERP” sont réservés à nos clients. N’hésitez pas à nous contacter pour avoir plus d’informations sur XiConnect en suivant ce lien : couplage entre Magento et les ERP.

Related posts:

1. Magento, l’atout pour votre eCommerce

-    un bug en production peut faire planter l’ensemble des sites.
-    un mauvais contenu en ligne peut se répercuter sur l’ensemble des boutiques

Aujourd’hui, nous avons décidé de réduire au maximum une activité chronophage et couteuse : le test manuel.

La maturité dans ce domaine de PHP ne nous propose pas le panel d’outils que nous avons l’habitude d’utilisé en Java, mais les premières briques sont là et vont bien nous aidé.

Les tests automatiques sont réalisés sur 2 niveaux :

1)    Test de fonctionnalité des principaux éléments du site, de la recherche de produit au processus de commande sous plusieurs modes en passant par la création de compte client.
2)    Test de contenu afin de vérifier que celui-ci n’as pas changé de façon non intentionnelle.

Ces tests une fois implémentés seront exécutés sur des serveurs d’intégration continu (reprenant à l’identique les serveurs de production). Ces tests automatisés seront exécutés automatiquement tous les jours sur la dernière version du code disponible en configuration (SVN, GIT).

Avec CubicTest, Selenium, Hudson, je m’assure d’avoir mon socle Magento fonctionnels de livraison en livraison.

La première partie a été réalisée avec CubicTest, un plugin Eclipse du logiciel de test reconnu Selenium.

La création des tests est relativement simple et rapide puisqu’il existe un mode enregistrement qui enregistre les opérations faites par l’utilisateur.

Le logiciel capte les actions réalisées dans le navigateur et les transforme en un test fonctionnel et facilement compréhensible grâce à l’interface graphique.

Ci-dessus un exemple de test simple réalisé avec CubicTest. Ce test exécute une recherche dans le moteur interne du site puis visite un lien du résultat.

En plus des fonctionnalités classiques il permet notamment de réaliser des tests personnalisés ce qui permet d’ajouter les interactions qui n’existeraient pas.

Il devient donc possible de constituer une véritable batterie de test pour passer en revue toutes les fonctionnalités vitales d’un site e-Commerce :
-    création de compte
-    mise au panier
-    processus d’achat
-    abonnement newsletter
-    navigation a facette
-    et tous les autres (mode grille/liste, prix, filtre, …)

La compatibilité avec des logiciels d’intégration continue tel qu’Hudson permet de réaliser une programmation des tests (journalière, hebdomadaire ou mensuelle par exemple en fonction des besoins).
Cela permet de recevoir par email par exemple les rapports des tests ayant échoués afin d’évaluer et de corriger les éventuelles erreurs.

Avec ce système de test automatisé réalisé de manière continue l’accessibilité et la fonctionnalité du site est vérifié, les problèmes sont donc corrigés au plus vite afin d’éviter toute perte trop importante.

Mon socle fonctionnel Magento est sécurisé, de quels outils je dispose pour la vérification du contenu qui peut être modifié par mon service client.

La deuxième partie qui concerne la vérification du contenu a été réalisée en Java.

Après avoir cherché et testé de nombreux softs de tests de contenu, nous avons opté pour développer notre propre moteur. En effet aucun ne répond suffisamment finement à notre besoin :

1. Parcourir un site entièrement
2. Historiser tous les liens du site ainsi que leur contenu à des dates précises
3. Pouvoir comparer les contenus du site actuel au contenu enregistré dans la base de référence.
4. Pourvoir changer le contenu de référence pour que les évolutions des contenus ne soit pas détecté comme des erreurs.

Ce développement maison s’intègre dans le processus d’intégration continue afin d’être alerté de toutes modifications non souhaitées.

Ces deux outils sont donc complémentaires pour vérifier l’intégrité et la fonctionnalité d’un site e-Commerce et ce particulièrement s’il est en évolution constante (vérifier que la correction d’un problème ou l’ajout d’une fonctionnalité n’entame pas le reste du site).

Si vous aussi vous souhaitez mettre en place ce type de processus, contactez nous par mail ou par téléphone au 05 61 82 58 86.

No related posts.

1. Étape 1

   Copier le ficher “/lib/Varien/Image/Adapter/Gd2.php” vers “/app/code/local/Varien/Image/Adapter/Gd2.php” en créant les répertoires manquant si nécessaire.

2. Étape 2

   Ouvrez le fichier Gd2.php (la copie, pas l’original) au environ de la ligne 80 et remplacer :

   call_user_func($this->_getCallback('output'), $this->_imageHandler, $fileName);


   par :

   if ($this->_fileType === IMAGETYPE_JPEG) {
call_user_func($this->_getCallback(’output’), $this->_imageHandler, $fileName, 90);
} else {
call_user_func($this->_getCallback(’output’), $this->_imageHandler, $fileName);
}

   Dans mon cas j’ai opté pour 90, mais vous pouvez faire varier cette valeur entre 0 et 100 de qualité.

3. Étape 3

   Pour déterminer, pensez à vider le cache des images via System > Cache Management.

Voilà, c’était simple, efficace et réutilisable sur n’importe quel projet, à partir du moment ou vous travaillez avec des images au format JPG et que votre serveur supporte GD2.

Source : http://narno.com/blog/augmenter-la-qualite-des-photos-sur-magento

No related posts.

- d’ameliorer son taux de transformation,

- de diminuer son taux de rebond,

- d’augmenter le nombre de creation de compte client,

- d’augmenter le nombre de creation de panier,

- d’augmenter son nombre de pages vues.

Avec ces objectifs en memoire, nous repensons regulierement les ergonomies de nos pages, avec tous les doutes que cela implique. Heureusement, sony Google l’a fait, l’outil Google Optimiseur de site.

Cet outil va permettre de tester differentes combinaisons et laisser l’utilisateur final nous demontrer quelle est l’ergonomie la plus pertinente. Pour faire simple, voici avec un exemple les etapes :

1. Definir ce que l’on souhaite ameliorer
   • ameliorer le taux de confirmation de commande
2. Imaginer les differentes ergonomies possible avec par exemple :
   • Mettre 2 boutons “commander” au lieu d’un,
   • Changer le texte de validation, etc…
3. Implementer ces differentes ergonomies
4. C’est ici qu’on intervient, ces implementations necessitent des competences en developpement (n’hesitez donc pas à nous appeler)
5. Suivre les resultats en observant les combinaisons les plus pertinentes.

En fonction du volume de visites/transformations, on obtient des resultats pertinents  plus ou moins rapidement.

Voici en pratique ce que cela donne pour quelques combinaisons de notre site de vente de vetements bio pour lequel nous avons mis en place 24 combinaisons possibles ( testees sur IE7 IE6 FF3 = 72 pages de tests) sur la page de liste des produits :

• Combinaison1
• Combinaison23
• Combinaison18
• Combinaison10

L’objectif etant de trouver une combinaison qui va ameliorer le passage de la page de liste de produit vers la fiche produit. Rendez-vous dans quelques jours semaines, des que Google  aura identifie les combinaisons gagnantes.

Voici le resultat d’un test qui vise a ameliorer le passage du blog a la boutique :

1. vetements bio – le blog – Original
2. vetements bio – le blog – Combinaison1
3. vetements bio – le blog – Combinaison2

Et voici le resultat apres 4 jours de tests seulement :

Nous sommes a priori sur une piste serieuse pour doubler le traffic entrant sur la boutique en provenance du blog !!!!! CQFD Merci Google.

En mettant ces techniques en place, on met l’amelioration de la performance au centre de sa strategie ecommerce et je pense que c’est un point au moins aussi important que les resultats pertinents que cela apporte.

Je vous exposerai dans la Partie 2 du sujet, le resultat du test des 24 combinaisons

Pour terminer, sachez que Magento supporte nativement Google Optimiseur de Site, en revanche il y a certaines limitations… suite dans le prochain episode.

No related posts.

No related posts.

• client (compte, carnet d’adresse, abonnement)
• commande (recapitulatif, tva, ligne de commande)
• produit (descriptif, image, stock)
• categorie (descriptif, lien avec les produits)
• coupons (nombre d’utilisation, validite)
• panier en cours

Cette etape est delicate dans un projet Magento, car :

• les imports natifs magento sont impossibles a faire tres long
• le modele de donnees magento est complexe

Nous avons donc mis en place une methodologie qui nous permet de convertir les donnees d’un systeme vers une base de donnees magento. Nous vous livrons en exclusivité la demarche que nous application sur ce type de projet.

A telecharger notre methodologie de migration magento

Extrait:

La problématique
Lorsque l’on parle de reprise (ou migration) de données, on a souvent tendance à ne penser qu’aux seules données stockées en base.
Pourtant, de nombreuses autres données peuvent être impliquées :
· Les images,
· Les fichiers de type média (fichiers audio, vidéo, flash…)
· Les fichiers de type documentaire (fichier Word, Excel, PDF…)
· Les fichiers de type personnalisation client fichiers CSV, XML…) qui stockent des informations personnalisées par vos clients en dehors de la base de données.
· …et d’autres types de fichiers auxquels nous n’avons pas encore pensés…

Ces types de données peuvent ou non être liées ou non aux données de la base.

La réponse Xi Ingénierie
L’une des premières étapes de la spécification détaillée de reprise des données consisté à justement identifier l’ensemble des données qui doivent faire l’objet de cette migration.

Pour chaque donnée identifiée, nous stipulons :
· Son type d’origine : base de données, fichier contenu, fichier de données…
· Son type de destination (idem)
· Son utilisation FO (Front Office) ou BO (Back Office)
· Les relations existantes entre les données
· Sa signification métier : l’utilisation qui en sera faite dans votre site eCommerce
· Les processus d’intégrité qui lui sont associés : par exemple, une adresse est nécessairement liée à une personne physique ou une entité juridique.

No related posts.

Voici en exclusivité notre eBook “Votre projet eCommerce : les atouts de Magento” from toulouse, il concerne la version community edition, c’est la premiere version, il y aura surement des ameliorations et/ou corrections.

Nous sommes partis du document anglais pour produire ce document de reference qui liste notamment toutes les fonctionnalites de magento

A Telecharger pour mieux connaitre Magento : Votre projet eCommerce : les atouts de Magento

Extrait:

WebMarketing promotionnel
Au cœur du site ecommerce, le marketing promotionnel est un des facteurs de ventes les plus importants. Notamment, Magento vous assiste fortement dans tout ce qui a trait aux ventes croisées et proposition de produits en fonction du contexte, et ce, jusqu’au moment de l’achat.
Par ailleurs, vous disposer d’un outil de gestion des promotions intégralement paramétrable : faites enfin les promotions dont vous rêviez !
Magento intègre aussi des fonctionnalités très appréciée comme les listes de vœux, les bons cadeaux, les sondages…

Related posts:

1. XiConnect, Notre solution de couplage Magento vers votre ERP ou SI

Version logicielle

Pour cet article, les versions utilisées sont les suivantes

* Flex 3
* ActionScript 3
* PureMVC 2.0.1

A qui s’adresse ce document ?

Ce document s’adresse en priorité aux personnes ayant des connaissances en Flex et en Action Script et qui ont une vision du travail qu’effectue PureMVC. Il nécessite donc de bien comprendre les notions de classes Action Script 3 et d’avoir un vue d’ensemble de la réalisation d’une application PureMVC.

Que contient ce document ?

Ce document contient un ensemble de bonnes pratiques à appliquer sur le projet. Il décrit le fonctionnement rapide et l’intérêt des concepts de pure MVC, ainsi que les structures de fichiers des projects et les séquences de démarrage d’une application pure MVC couplée à Flex.

Principe de fonctionnement de PureMVC

Ce paragraphe a pour objectif de faire un rapide tour d’horizon des notions qui entoure PureMVC.

L’application Façade

L’application facade est, dans PureMVC, l’interlocuteur privilégié pour tous les “acteurs” du projet. C’est elle qui va démarrer le système PureMVC, en initialisant les différentes commandes et envoyant les messages de démarrage. C’est aussi à elle que l’on va s’adresser pour récupérer une instance sur un proxy, ou pour enregistrer un proxy.

Règles de nommage : La facade étant unique dans une application, on la nommera toujours ApplicationFacade.

Les notifications

Les principes de base dans PureMVC résident dans les notifications, qui permettent le dialogue entre les différentes couches de l’application. Une notification est capable de transporter un objet qui sera utilisé par l’intercepteur pour réaliser son travail.

Règles de création: La constante représentant une notification est toujours écrite dans le proxy qui est en charge de la notification. Dans le cas où aucun proxy n’intervient alors on devra faire en sorte que la constante se trouve dans la vue qui doit l’envoyer.

Règles de nommage : Les notifications seront suffixées par “_NOTIFICATION”. Cela permet en particulier de les distinguer des événements.

Les Médiators

Au sein de PureMVC, l’objectif des médiators est de faire l’interface entre la partie vue et la partie les couches sous-jacentes de l’application PureMVC. Dans un premier temps, il se charge simplement de recevoir les évènements en provenant de la vue et de créer les notifications qui correspond. Dans un deuxième temps, il reçoit les événements de la couche model et met à jour la vue en conséquence.

Règle de créations : On crée en général un médiator par composant qui envoie plusieurs évènements, afin de ne pas multiplier les médiators effectuant des actions qui pourraient être regroupées. Ainsi, si on a un panel avec 3 boutons et une liste, il sera conseillé de créer un médiator pour le panel qui réceptionnera les informations du panel et les informations des boutons et un médiator pour la liste qui prendra en charge les événements en provenance de la liste s’ils sont nombreux.

Règles de nommage : Le nom d’un médiator doit être composé sous la forme “nomdelavueconcernée”+”Mediator”

Les Commands

Les commandes sont des classes qui vont être enregistrées sur les notifications qui transitent dans PureMVC. L’objectif de ces classes est d’effectuer des actions complexes pour le compte de la vue. La question qui se pose est de savoir pourquoi on n’utilise pas directement les médiators pour effectuer les actions sur le modèle. Sans l’utilisation des commandes, le médiator va contenir l’ensemble des actions à effectuer et de ce fait toute réorganisation de la vue va entrainer une réorganisation du code contenu dans les médiators. Par ailleurs si on souhaite effectuer la même commande sur une autre notification on va devoir dupliquer le code.

Règles de création : D’une manière générale on créera des commandes pour toutes interactions avec les modèles via les proxy, à partir du moment où l’on veut faire autre chose qu’une consultation. D’une manière plus spécifique, on créera une commande lorsque l’action qui devra être réalisée est complexe et lourde ou lorsque l’on souhaite connecter la même action sur plusieurs notifications.

Règles de nommage : Le nom d’une commande doit forcément se terminer par le mot clé “Command”.

Les Proxy

L’objectif des proxy est de venir masquer l’interaction avec les modèles métier et les services. Il offre un ensemble de méthode et prend en charge ensuite l’appel aux services, la modification de données etc… Le principal avantage du proxy est de permettre la modification de l’appel à un service sans avoir à impacter l’ensemble du code nécessitant ce service. Il masque l’utilisation des services et de ce fait permet la réalisation de services fictifs répondant à un besoin mais qui n’effectue pas d’action sur le modèle. Cette technique permet de travailler sur un interface en flex sans que l’appel réel aux services soit réalisé.

Règle de création : On créera un service par objet qui va transiter vers les services via par exemple AMF PHP.

Les Values Objects

Un value object est un conteneur d’information, qui permet de faire transiter des données entre les différents couches de l’application. Ces objets sont une représentation d’un groupe de données qui transitent au sein de l’application. On utilise principalement les values objects au moment de la présentation des données en les “bindant” aux champs du formulaire flex. Ceci permet ensuite la récupération d’un objet dont les données sont automatiquement complétées par les mécanismes Flex.

Règle de création : On créera un value object pour représenter un élément complexe de l’application et lorsque l’on aura besoin de faire transiter un groupe d’informations via les notifications. Par exemple si on dispose d’un ensemble de formulaire éditant tout ou une partie des propriétés d’un objet métier, on va donc créer un Value Object qui rassemblera l’ensemble des propriétés des différents formulaire afin de centraliser l’information.

Structure du projet

Le répertoire ressources

Le répertoire ressources contient l’ensemble des ressources qui vont être embarquées dans l’application avec la spécification embed. Il contient généralement les images et surtout les fichiers de locales qui vont être chargés lors du démarrage de l’application.

Le répertoire src

Ce répertoire contient les sources de l’application et est structuré en trois packages.

* Le package controller

On regroupera dans ce package l’ensemble des commandes de l’application.

* Le package view : c’est dans ce package seront regroupé l’ensemble des médiators mais aussi l’ensemble des composants Mxml de l’application. Il est important de suivre la règle de création suivante pour les sous packages : un sous package par groupe de médiators et composants. Tous médiators qui concernent un composant particulier seront groupés.

* Le package model: on retrouvera dans ce package l’ensemble des proxy ainsi que les values objets de l’application. Les value objets sont placés ici pour éviter les dépendances montant entre les proxy et les deux couches supérieures contenant les commandes et les vues.

Séquence de démarrage d’une application Flex 3 couplée à PureMVC

Dans le cadre d’un modèle MVC standard, il est généralement préférable de faire démarrer l’application par le biais d’un controller qui va initialiser l’ensemble des intervenants de l’application. Cette stratégie n’est pas applicable dans le cas de Flex, puisqu’il existe une application par défaut dans flex. L’application par défaut (fichier Mxml) qui va être appelée par le runtime de Flex au démarrage de l’application. On se retrouve donc dans un position inversée : La vue démarre l’application, sans être au préalable assurée de la disponibilité des autres intervenants.

Exemple de démarrage d’un application PureMVC

Pour palier à ce problème il faut donc faire en sorte que la vue démarre l’ensemble de l’application de manière correcte afin d’éviter d’éventuels problèmes d’accès à des objets non existant. Pour ce faire, il est nécessaire d’utiliser l’application facade, qui elle va prendre en charge le démarrage de l’application. On suivra donc les étapes suivantes :

1. Création d’un médiator pour la vue application ApplicationMediator. Ce médiator va prendre en charge les évènements et le comportement de l’Application par défaut flex.
2. Créer une macro commande ApplicationCommand qui va prendre en charge le démarrage de l’application.
3. Rajouter dans l’initialisation de l’applicationCommand, deux sous commandes : ModelPreparationCommand et ViewPreparationCommand.
4. Le corps de la commande de préparation du model “ModelPreparationCommand” enregistre l’ensemble des proxys nécessaire à l’application.
5. Le corps de la commande de préparation de la vue “ViewPreparationCommand” enregistre le médiator de l’application (Application Mediator) et lui demande d’afficher la première vue (généralement, on effectue un changement d’index sur une stack).
6. L’application mxml récupère une instance de l’application facade et le onCreationComplete execute la fonction startup de l’applicationFacade.
7. A son initialisation l’applicationFacade enregistre la commande ApplicationCommande sur la notification Startup puis la fonction startup de l’applicationFacade envoie la notification de démarrage de l’application :

override protected function initializeController():void

{
 //initialise les controllers.

 super.initializeController();

 //register the application on the startup notification.

 this.registerCommand(STARTUP_NOTIFICATION,ApplicationStartupCommand);            

}

public function startup(flexApplication:ArchectypeApplication ):void
{

 this.sendNotification(STARTUP_NOTIFICATION, flexApplication);

}

Gestion de évènements et des notifications

Utilisation des values objects

Comme nous l’avons vue précédemment, il est important de disposer de value object pour pouvoir faire transiter l’information correctement entre les différentes couches. Un fois la classe value object définie, on va créer un instance dans la vue et la rentre public et bindable de la manière suivante:

[Bindable] public var categoryVO:CategoryVO = new CategoryVO();

L’objectif est ici que l’on puisse récupérer l’object par le médiator pour l’envoyer dans la notification.
Création et remontée des évènements dans la vues

L’objectif dans l’utilisation de PureMVC est que la vue Flex (fichier MXML) ne connaisse pas du tout son médiateur, afin que l’on puisse changer à volonter le médiateur gérant les évènements. Pour pouvoir effectuer ce découplage, la stratégie consiste faire remonter les évènements vers les éléments à l’écoute du composant.

Pour cela on crée un ensemble de constantes qui vont définir les évènements :

/**
* Type d’évènement envoyé lors du clique sur le bouton de suppression.
*/
public static const DELETE_EVENT:String = “DELETE_EVENT”;
/**
* Type d’évènement envoyé lorsque le composant à été crée complètement
*/
public static const CREATION_COMPLETE_EVENT:String = “CREATION_COMPLETE_EVENT”;

On créera ensuite un fonction pour renvoyer les évènements vers les listeners :

/**
* Méthode qui intercepte les évenments sur les boutons.
* @param type le type d’évènement qui est interceptés.
*/
public function handleButtonEvent(type:String):void
{
//Dispatch les évènements vers les listeners
dispatchEvent(new Event(type));
}

Et on branchera ensuite cette fonction sur les différents évènements comme par exemple sur un bouton :

<mx:Button x=”317″ y=”71″ width=”100″ label=”Supprimer” click=”handleButtonEvent(DELETE_EVENT)” id=”deleteButton”/>

Une des pratiques importantes est de documenter ces évènements grâce au méta-data :

<mx:Metadata>
/**
* Evènement déclenché lorsque la création du composant est terminée.
*/
[Event("CREATION_COMPLETE_EVENT")]

/**
* Evènement déclenché lors de la mise à jour de la sélection sur la liste.
*/
[Event("SELECTION_CHANGE_EVENT")]
</mx:Metadata>

On spécifie ici que la vue en question va envoyer un évènement SELECTION_CHANGE_EVENT et un évènement CREATION_COMPLETE_EVENT et les commentaires apparaitront dans la documentation générée grâce à asdoc.

Réception et traitement des évènements dans les médiators

Dans le paragraphe précédent nous avons vu que les vues remontaient des évènements suites à des actions de l’utilisateur. Sachant que le médiator d’une vue est la pour faire le dialogue avec les couches inférieures, on l’enregistrera de la manière suivante sur les évènements de la vue :

categoryScreen.addEventListener(CategoryScreen.DELETE_EVENT, onEvent);
categoryScreen.addEventListener(CategoryScreen.CREATION_COMPLETE_EVENT, onEvent);

Dans ce code, categoryScreen est le composant mxml sur lequel sont enregistrés le médiator et onEvent est la fonction qui va traiter l’évènement. Dans la fonction onEvent, on va faire en sorte d’envoyer une notification, qui sera interceptée par la couche commande pour effectuer le travail désiré:

public function onEvent(event:Event):void
{
[...]
switch (event.type)
{
[...]
case CategoryScreen.DELETE_EVENT:
//envoie d’une notification contenant l’élément à supprimer
category = this.categoryScreen.categoriesList.selectedItem as CategoryVO;
facade.sendNotification(CategoryProxy.CATEGORY_DELETE_NOTIFICATION, category);
break;
}
}

Il est à noté que l’on évitera de faire un succession d’accès par l’opérateur “.” aux éléments fils d’une vue. L’exemple présenté ici est en partie un contre exemple. Ce qu’il est important de noté est la récupération du value object.

Séquence de propagation des évènements

La séquence de propagation des évènements est la suivante

1. L’utilisateur clique sur un bouton ce qui déclenche un évènement
2. L’évènement est intercepté par la vue et dispatcher aux listeners
3. Le médiateur qui est à l’écoute sur l’évènement, est alerté et envoie un notification
4. La commande reçoit la notification et fait appel au proxy pour exécuter les appels
5. Si l’appel se déroule bien alors le proxy envoie une notification de mise à jour
1. le médiator intercepte la notification
2. le médiator fait appel au proxy récupérer les valeurs.
3. le médiator met à jour la vue avec les données du proxy.
6. Si l’appel ne se déroule pas bien le proxy ou la commande envoie un notification de problème
1. le médiator intercepte la notification de problème.
2. le médiator affiche le message d’erreur.

Stratégie d’enregistrement des médiateurs

Un médiator est toujours enregistré sur un vue existante. Cependant, en raison de l’initialisation à la demande des composants en Flex, on se retrouve régulièrement dans le cas d’un appel à une instance d’un object qui n’existe pas.
L’évènement onCreationComplete

Cet évènement est déclenché lorsque tout les composants ont été initialisé. Cependant dans le cas d’un accordéon qui contient deux canvas, eux même contenant deux boutons, l’évènement onCreationComplete apparait lorsque les deux canvas on été initialisé, mais les boutons du deuxième canvas n’ont pas été crée. On recoit donc un évènement lorsque les deux éléments fils ont été crée.

onCreationComplete with flex

Création des médiateurs

Pour palier aux problèmes évoqués précédemment, il est nécessaire de faire en sorte que la création des médiators fils se fasse de la manière suivante :

Exemple de séquence de création de médiateurs

1. On part du postula que le médiator du composant parent ainsi que le composant parent ont été créés
2. Le mediator du composant parent s’enregistre sur l’évènement creation complete du composant parent
3. L’évènement CreationComplete du composant parent est déclenché, on sait alors que tout les composants fils de premier niveau ont été créés.
4. Le médiator du composant parent crée alors les médiators pour les composants fils et les enregistre sur les composants fils.
5. Les médiators du composants fils s’initialisent et s’enregistrent sur les évènements des composants concernés.

Résumé des règles

1. Utiliser des values objects pour le transport des informations
2. Utiliser la méthode “DispatchEvent” pour la gestion des évènements sur les vues
3. Utiliser le mediator comme simple intermédiaire entre les vues et les couches inférieures.
4. Préferer l’utilisation des commandes au placement de la logique métier dans la vue

No related posts.

Alfresco est une solution Open Source sous licence LGPL1 de gestion de contenu d’entreprise créée en juin 2005. C’est un système ouvert et basé sur la technologie J2EE JSF (Java Server Faces) permettant la gestion de contenu d’entreprise et l’accès fluide et aisé au contenu pour les différents utilisateurs. Cette solution utilise de nombreux outils libres reconnus comme Tomcat (serveur Web et compilateur JSP), HSQLDB (base de données relationnelle en Java), Lucene (moteur de recherche libre en Java), et bien d’autres…

Alfresco propose de nombreuses fonctionnalités, notamment :

• Solution libre
• Peu gourmand en ressources serveur
• Système CIFS
• Accès via une interface web ou explorateur via CIFS
• Facile à administrer via l’interface web
• Possibilité d’éditer des documents en ligne ou via CIFS
• Mise à jour automatique lors des modifications de documents
• Gestion des droits et de l’accès en fonction des utilisateurs

Versions

Pour un topo sur les versions suivez ce lien : Alfresco Versions

Développement

Cas d’utilisation du client web

Liste des Fonctionnalités pour les modifications

Environnements de développement

SDk

Alfresco propose dans le cadre de sa logique Open Source un standard développement Kit téléchargeable sur le site de sourceforge. Cet SDK est la méthode la plus simple pour apprendre a l’application Alfresco et a créer des plugins.

SVN

Alfresco propose un répertoire subversion accessible a tous en lecture. Il est ainsi possible pour tout développeur désireux de le core de l’application. Mais, dans notre cas, comme nous voulons faire du suivi de version il est plus conseillé de ne pas utiliser cette méthode, il sera plus logique de passer par un système de plugins.

Les possibilités de développement

Java script API

Alfresco propose une bibliothèque afin de faciliter l’écriture de java scripts directement exécutables dans le web client. Les scripts java script exécutés sur le client proposent même d’inclure d’autres scripts, on peut ainsi créer des bibliothèques de java script.
http://wiki.alfresco.com/wiki/JavaScript_API

Content Management Web Services API

Les web services proposent de nombreuses actions sur le contexte Alfresco. Alfresco propose ainsi, des services sur l’authentification, les repositories, les actions… mais aussi, des services sur les données et les métas donnés ainsi que sur les SOAP headers et un langage de requête.
http://wiki.alfresco.com/wiki/Alfresco_Content_Management_Web_Services

Content Management Java API

Alfresco’s Content Management Java Services API est un ensemble de services qui permettent un accès complet au dépôt des fichiers d’Alfresco.
http://wiki.alfresco.com/wiki/Alfresco_Content_Management_Java_API

Java Content Repository (JCR) API

Méthode standard pour travailler sur les fchiers Alfresco
http://wiki.alfresco.com/wiki/Introducing_the_Alfresco_Java_Content_Repository_API

Web Script

http://wiki.alfresco.com/wiki/Web_Scripts
Pour plus d’infos : alfresco:webscript

Cahier des charges XI

• Alfresco:cahier des charges xi
• Alfresco:calendrier du développement

Tutoriaux

• Alfresco:Module Management Tool
• Alfresco:Acceder au CIFS avec firefox

Liens

• Forum
  • Le forum francophone: http://forum.alfresco-fr.org/
  • Le forom anglais : http://forums.alfresco.com/

• Téléchargement :
  • La page sourceforge : http://sourceforge.net/project/showfiles.php?group_id=143373

• Wiki:
  • Français : http://wiki.alfresco.com/fr/index.php/Accueil
  • Anglais : http://wiki.alfresco.com/wiki/Main_Page

• Developpeurs
  • Developer Guide: http://wiki.alfresco.com/wiki/Developer_Guide
  • Repository architecture: http://wiki.alfresco.com/wiki/Alfresco_Repository_Architecture
  • SDK: http://wiki.alfresco.com/wiki/Alfresco_SDK
  • SVN Dev Env.: http://wiki.alfresco.com/wiki/Alfresco_SVN_Development_Environment

• Forge:
  • http://forge.alfresco.com/ (Pour les projets développés par des particuliers en complément à Alfresco)

• Javadoc :
  • http://wiki.alfresco.com/wiki/Alfresco_JavaDoc

• Divers
  • Site d’un developpeur alfresco avec de trés bon tutoriaux : http://ecmarchitect.com/alfresco-developer-series/

No related posts.

Dans cette article nous allons aborde la problematique de la migration de données sous Magento. En effet meme si Magento propose en standard des formats d’import, ceux ci sont tous simplement inutilisable lorsqu’il y a du volume.

Nous avons donc mis en place un projet specifique avec Talend, qui nous permet d’importer les données depuis oscommerce ou autre source vers Magento. Cette migration s’appuie sur une methodologie qui fonctionne pour toutes source de donnees, aujourd’hui nous avons developpe des sous projet de migration pour :

• osCommerce
• Divalto
• Fichiers Excel.

Voici les grandes lignes :

1) Magento et son schema de base

2) Avoir un projet Talend lisible et maintenable

3) Les schemas intermediaires de Xi Ingenierie :

• une base de données normaliser Xi (tres lisible)

• des fichiers excel normalisé également.

4) l’importation en 2 phases.

• importation du standard magento
• importation du specifique

Vous trouverez plus en detail notre demarche dans le billet/document relatif a la migration magento

Related posts:

1. La reprise de donnees vers une base Magento