Développement d'interfaces
Nous avons réalisé un grand projet de plusieurs mois en sous-traitance pour une entreprise de logiciels prospère. Il s'agissait de créer une interface personnalisée d'un système de gestion des marchandises propriétaire pour Joomla/Virtuemart. De nombreux obstacles techniques ont dû être surmontés : Comment les données sont-elles récupérées ? Comment les données doivent-elles être présentées au final ? Nous donnons ici un bref aperçu du projet et de notre approche.
Le problème se présentait comme suit : Le client met à disposition un système de gestion des marchandises propriétaire qui dispose d'une énorme base de données en arrière-plan. Le système est continuellement mis à jour et modifié. Des catalogues sont par exemple générés à partir des données qui y sont stockées ou des informations sont fournies aux clients. Le système dispose de plusieurs interfaces, dont des requêtes standardisées via MySQL. C'était notre point de départ : le client souhaitait que le catalogue soit chargé dynamiquement dans un catalogue basé sur le web sans aucune intervention extérieure, qu'il soit consultable et qu'une URL toujours valable ainsi qu'un code QR soient générés pour chaque article et qu'ils puissent être limités par de nombreuses propriétés de filtrage et de recherche. La solution devait être conçue de manière modulaire pour une utilisation dans Joomla et, plus tard, dans Typo3, ainsi que pour une intégration complète dans un système de boutique.
Nous avons d'abord demandé au client de nous expliquer le problème en détail et nous avons fixé des étapes avec lui. À partir de ces étapes, nous avons d'abord établi un devis, puis nous l'avons intégré dans tous les systèmes impliqués. Ensuite, sur la base de cette familiarisation, nous avons créé un prototype qui devait démontrer et garantir la fonctionnalité de base du système. Ce prototype était déjà opérationnel après une journée de travail.
Après la conception et l'élaboration de l'interface, la recherche de solutions fonctionnelles pour le système de gestion de contenu a suivi. „Joomla“, Nous avons pu mettre en place notre solution sur cette base. Nous avons rapidement trouvé un accord avec „VirtueMart“ une plateforme populaire et prometteuse, dont nous avons pu utiliser la technologie et l'étendre progressivement.
Nous avons dû créer directement deux connexions et écrire un traducteur : D'un côté, la structure propriétaire du système de gestion des marchandises du client est lue, traduite et normalisée par notre système, et de l'autre, elle est réémise ou importée dans VirtueMart. Ce module, avec ses milliers de lignes de code réparties sur une architecture bien structurée en PHP, est à lui seul absolument unique.
En plus de ce traducteur, plusieurs adaptations de la présentation ont été nécessaires. Nous avons rapproché autant que possible les fonctionnalités souhaitées des modules déjà disponibles, afin de minimiser les coûts pour le client. Nous avons adapté ces modules de manière plus approfondie, par exemple les URL du front-end ont été conçues de manière „parlante“ - et il est désormais possible de s'adresser aussi bien aux produits qu'à n'importe quel niveau de structure de produit, ce qui n'était pas possible sans autre. Grâce à notre adaptation, il est notamment possible d'attribuer autant de catégories et de niveaux de structure que souhaité, car la base de données est décomposée de manière dynamique en ses éléments. L'implémentation a été conçue de manière totalement indépendante de Virtuemart et du design, ce qui signifie en clair que l'on peut prendre n'importe quel Joomla avec Virtuemart et „lâcher“ notre extension, Virtuemart étant ensuite alimenté et modifié avec les données du WWS. Cela rend la solution hautement portable ! De même, une mise en œuvre dans Typo3 a déjà été prévue et préparée en conséquence.
Lorsque des images de produits sont disponibles dans la base de données, le client souhaitait que les images soient automatiquement importées et associées au frontend. Différentes tailles sont générées pour les vignettes et pour l'affichage final.
Pour chaque produit, le front-end propose une fonction pour générer un PDF, „Ask a question“, envoyer/partager, etc. En outre, le client et l'utilisateur peuvent désormais filtrer les produits de manière dynamique et définir précisément les propriétés à afficher pour le filtrage. De même, le client peut définir séparément pour chaque article les propriétés qu'il souhaite afficher, les informations contenues dans un article et les fonctions disponibles pour l'utilisateur dans l'aperçu des articles. Cela peut déjà être déterminé de manière flexible du côté de la base de données dans le système de gestion des marchandises ! Les titres et les identificateurs peuvent être modifiés de manière dynamique dans la base de données, sans que la génération du code QR en soit affectée : Une fois définis, les liens restent valables.
Il est également possible de déterminer si l'on souhaite trier/filtrer avec des cases à cocher, des boutons radio, des listes déroulantes, etc. Le filtrage fonctionne en temps réel sans rechargement de la page. Le filtrage s'adapte de manière dynamique. Pour cela, une extension a été entièrement adaptée et réécrite afin de pouvoir fonctionner avec ou sans Ajax.
L'ensemble de la solution est préparée comme une boutique et peut également être dotée de prix si cela est souhaité. En outre, la connexion à la base de données a été conçue de manière dynamique, de sorte que le client peut à tout moment ou partiellement relire la base de données via une fonction dans le backend, ou encore le faire via une commande extérieure („Cronjob“) peut être déclenchée. Pour ce faire, une autre interface a été créée vers l'extérieur et le domaine backend de Virtuemart a été étendu.
German 
English 
French 
Italian