Développement de modules et d'interfaces personnalisés

Développement de modules et d'interfaces personnalisés

Développement d'interfaces

Développement de l'interface Image symbole avec puzzle sur Macbook

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.

Définition du problème

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.

Approche

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.

Particularités et Fonctions spéciales

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.

Punctum.fr

Punctum.fr

SEO et développement de concept de site web

Punctum.fr ouvert sur smartphone, desktop et tablette
 Punctum.fr est le site de la société Punctum KG de Lohfelden qui, outre une expertise avérée en matière de bases de données et de modules SAP, fait avancer, propose et gère ses propres projets.

En collaboration avec la direction de Punctum AG, nous avons réalisé un nouveau concept de site web. L'objectif était d'obtenir une structure conservatrice et flexible qui s'inspire du design en tuiles de Windows 8. Le site a été conçu par le client lui-même, qui en assure également le suivi grâce à une formation en direct.

Profizelt24.de

Profizelt24.de

Pour le spécialiste de l'événementiel et des tentes Tente professionnelle24 nous avons adapté et étendu le modèle eBay existant à un nouveau logiciel de gestion.

Il s'agissait de faire appel à des compétences créatives ainsi qu'à quelques trucs et astuces dont il faut tenir compte sur eBay.

Développement de logiciels de gestion

Profizelt24.de ouvert sur smartphone, desktop et tablette
Mariomerkle.ch

Mariomerkle.ch

Site Internet de Mario Merkle (Mariomerkle.ch) , ouvert sur un iMac

Développement du backend

Mario Merkle est un artiste suisse dont le site web statique existant devait être complété par des fonctionnalités.

Jusqu'à présent, chaque nouveau travail de l'artiste devait être intégré manuellement dans le code HTML, en faisant attention à de nombreux détails techniques, ce qui ne facilitait pas les choses. Il fallait également créer soi-même des images d'aperçu pour les travaux.

Un backend a été mis en place pour permettre à l'artiste une gestion simple. Il est possible de créer de nouveaux travaux, d'en éditer d'autres ou de les supprimer.

L'ordre des travaux peut également être modifié par glisser-déposer. Des vignettes aussi attrayantes que possible sont automatiquement générées pour les travaux téléchargés. Notre solution a été intégrée dans le système existant et existe encore aujourd'hui ; elle peut être téléchargée sous https://www.mariomerkle.ch/ peuvent être visités.

Google Maps® API

Google Maps® API

Dans le cadre de cette commande, un script a été développé, qui s'appuie sur l'API Google Maps pour afficher les limites des zones de codes postaux. Pour ce faire, l'API Google Maps, l'API Google Geolocation et l'API Google Fusion Tables ont été combinées. Le jeu de données de base suivant, disponible dans le domaine public, a été utilisé pour les limites territoriales. Ensemble de données a été utilisé. Celui-ci devait encore être adapté et converti.

API de géolocalisation de Google

Google Maps® Recherche par code postal Extrait
Google Maps® API Zones de code postal sur un Macbook

De plus, toutes les limites territoriales sont signalées par un marqueur (le code postal). Ce marqueur est également sélectionnable, ce qui ouvre une fenêtre pop-up qui peut être complétée par le texte de votre choix. Dans l'image d'exemple, on peut voir que le code postal est affiché, ainsi qu'un autre texte avec un lien qui contient également le code postal, de sorte que celui-ci pourrait être utilisé à d'autres fins.

Le script réagit aux paramètres GET du navigateur, qui déterminent la couleur et la sélection des codes postaux. Un exemple d'appel avec un seul code postal se présenterait comme suit avec les paramètres par défaut : ?script.php ?zip=46509&mColor=ff0000. Les noms des paramètres peuvent être modifiés à volonté.

Comme l'objectif du projet était de pouvoir marquer les codes postaux environnants d'un code postal principal avec deux couleurs différentes, d'autres paramètres sont également disponibles : script.php ?zip=46509&mColor=ff0000&rZip=46459,47665&rColor=0000ff&fZip=46487&fColor=00ff00.

Comme on peut le voir dans l'exemple, il est possible d'indiquer plusieurs codes postaux, séparés dans ce cas par une virgule. Le séparateur peut également être modifié à volonté. Le script accepte donc 3 types de codes postaux différents, chacun avec une couleur, et les affiche en couleur sur une carte Google Maps.

L'avantage de l'implémentation est que le script peut être intégré dans des pages web existantes. Soit comme une carte dynamiquement mobile, soit comme un extrait d'image. Un scénario d'utilisation possible pourrait être une boutique qui ne livre différents produits que dans certaines régions. Le script pourrait être intégré dans la description détaillée des produits et afficher les régions dans lesquelles le produit peut être livré en deux couleurs, pour „disponible immédiatement“ ou „actuellement épuisé“. Le script peut également être étendu à d'autres couleurs et types de codes postaux, ce qui permet d'envisager une multitude d'autres scénarios d'utilisation.