Bonjour à tous,

Je discutais avec Loïc sur la possibilité d'avoir une fonction d'import / export des catégories et produits dans WWStore. Le cas est prévu dans DNN. L'API possède une interface IPortable qu'il "suffit" d'implémenter. Je venais de terminer l'implémentation sur le module Menu (catégories), lorsqu'une petite voix s'est fait entendre dans mon esprit...

L'import / export des catégories fonctionne très bien. Mais ! Chaque catégorie est identifiée par un ID, chose assez commune me direz-vous. Comme c'est une colonne auto-numérotée, l'ID change lorsque l'on importe les catégories précédement sauvegardées.

Vous : Oui, et alors ?

Et bien, le problème c'est que les produits sont liés à une catégorie par son ID ! Donc on peut certe sauvegarder, mais les produits ne sont plus liés car l'ID a changé. Pour palier à cela, on pourrait faire l'import / export sur le module StoreFront et prendre en compte les catégories par leur nom et lier les produits sur celui-ci dans le fichier xml. Ce qui permettrai de pouvoir lier à nouveau les produits aux catégories lors de l'import. Il sufit de charger d'abord les catégories et de les conserver en mémoire dans un tableau. Puis de charger les produits et pour chacun d'eux de retrouver l'ID du nom de la catégorie correspondante dans le tableau et d'ajouter le produit avec l'ID de la catégorie. Ouf !

Vous : Tu vois que tu trouve tout seul la solution quand tu veux bien réfléchir un peu !

Oui, mais ! Les commandes et les avis sont aussi liés sur les produits. Voyez-vous où je veux en venir ? Qu'à cela ne tienne ! On pourrait aussi les sauvegarder, en implémentant les fonctions plutôt sur le module Admin. Et puis tant qu'on y est, pourquoi ne pas sauvegarder aussi les paramètres du magasin. Après tout ce ne serait que quelques lignes de plus. Seulement, demain il y aura peut-être aussi le taux de TVA par produit. Qui sera lié à la table des taux évidemment. Et ainsi de suite...

Comme je viens de passer de quelques dizaines de lignes d'implémentation à probablement plusieurs centaines. Je vous pose les questions suivantes avant d'aller plus loin :

1. Est-ce vraiment nécessaire ? SQL Server et des modules de backup font déjà cela très bien.
2. Si oui. Que doit-on sauvegarder ?
   1. Juste les catégories et les produits afin d'avoir une copie du catalogue complet uniquement ?
   2. Toutes les informations de la boutique pour pouvoir "migrer" l'ensemble sur un autre serveur ?

J'attends vos avis (c'est de saison avec les élections), alors exprimez-vous !

Gilles (qui-parle-tout-seul-et-qui-fait-les-questions-et-les-réponses-mais-pas-toutes)

Pour la raison que donne mick2k6 c'est clair que ça serait bien, mais c'est clair aussi que cela représente un sacré boulot.

Difficile de voir petit sur ce genre de développement car tout est lié. Alors oui ça serait super un Import/Export mais qui s'y colle ?

Je sais que moi je n'ai jamais été très branché par les champs de type uniqueidentifier c'est toujours galère pour faire ce genre de truc. Mais c'est ainsi.

Le fait de vouloir casser le lien sur l'ID moi ça me fait franchement peur car comme je le disais plus haut bonjour le developpement et la maintenance d'un truc pareil. Ne pourrait-on pas exporter les données telles quelles avec tout les IDs (et donc les liens entre les données) et c'est lors de l'import que l'on fait un traitement particulier lors de l'insertion d'un élément dont l'ID est recalculé. Il faudrait alors répercuter ce nouvel ID sur les données de notre fichier export.

En creusant bien ça m'étonnerait pas qu'on arrive à automatiser ce traitement : pour chaque colonne de type uniqueidentifier on doit récupérer son nouvel ID lors de l'insertion de l'enregistrement, on impacte alors ce nouvel ID sur les données exportées et on continue notre import. C'est très très rapidemment brossé mais ça doit pouvoir se faire non ?

En tout cas je sens pas trop le coup de s'appuyer sur les libellés pour les liens entre les données.

Bonjour Loïc,

Comme je viens de l'expliquer à Mick, je mis suis collé ! Du moins pour la partie catalogue.

J'ai choisi d'utiliser le nom de la catégories pour faire le lien. Sans quoi, il faudrait deux tableaux des catégories en mémoire. Le premier avec les ID d'origine et un second avec les nouveaux ID. Voici un exemple de fichier exporté :

<?xml version="1.0" encoding="utf-8" ?>
<content type="WWStoreMenu" version="02.00.06">
<Categories>
   <Category>
      <Name>Logiciels</Name>
      <Description>Logiciels communs</Description>
      <Message />
      <Archived>False</Archived>
      <OrderID>1</OrderID>
      <ParentCategoryName>Aucune</ParentCategoryName>
   </Category>
   <Category>
      <Name>Matériels</Name>
      <Description>Matériels communs</Description>
      <Message />
      <Archived>False</Archived>
      <OrderID>1</OrderID>
      <ParentCategoryName>Aucune</ParentCategoryName>
   </Category>
   <Category>
      <Name>DotNetNuke</Name>
      <Description>Produits relatifs au portail Open Source DotNetNuke</Description>
      <Message />
      <Archived>False</Archived>
      <OrderID>1</OrderID>
      <ParentCategoryName>Logiciels</ParentCategoryName>
   </Category>
</Categories>
</content>

Comme tu peux le remarquer, il n'a aucun ID (OrderID, c'est l'ordre d'affichage). En revanche, le lien est fait avec le champ ParentCategoryName. Lorsque je charge les lignes dans la base, je conserve l'objet CategoryInfo avec son nouvel ID dans un tableau. Avant chaque insertion, je parcours le tableau pour trouver le nom du parent et récupérer son nouvel ID. Simple et efficace. La seule limitation est qu'il ne doit pas exister deux catégories avec le même nom ! Ce qui normalement ne devrait pas arriver. Au pire dans ce cas les produits liés sur la seconde seraient liés avec la première. Au final la seconde sera tout simplement vide. On pourrait même considérer cela comme une correction automatique de la logique des catégories. Puisque je ne vois pas l'utilité d'avoir deux catégories du même nom, sauf pour pertuber l'internaute qui trouverait alors une partie des prodits sur l'une et le reste sur la seconde.

Gilles

Fichtre, bigre, saperlipopette, sacrebleu !!

Je n'avais pensé à cela. Tu as raison, il va falloir que je modifie le traitement. Je vais donc conserver l'ID à l'export et stocker les paires ancien / nouvel ID dans un tableau pour faire la correspondance correcte.

Loïc 1 / Gilles 0

Pour les prix multiples, c'est difficile. Il faudrait dans ce cas pouvoir créer dynamiquement des colonnes. Le problème serait ensuite de savoir quelle colonne afficher. Car le template est le même pour tous les produits. Je ne vois pas comment nous pourrions faire sans tout modifier.

Gilles

J'ai modifié l'import / export pour qu'il se base sur les id et non plus sur les libellés. J'ai modifié aussi une procédure stockée pour obtenir les catégories triés par CategoryParentID.  C'était la seule solution pour ajouter les catégories sans faire un update pour mettre à jour ensuite les id des parents.

Du coup, j'utilise un SortedList des paires de clefs ce qui est plus rapide aussi et prend moins de place mémoire. Même avec plusieurs centaines de catégories cela n'aurait pas fait une différence énorme. Mais bon, c'est plus pour la forme.

Gilles