Author: Romain Dunand

Tableau est un puissant outil d’analyse des données et depuis peu, il est devenu possible d’y connecter nos bases de données FileMaker à l’aide d’un connecteur dédié livré avec la version 16 de FileMaker Server.

Alors que nous testions ses possibilités dans le but d’en faire profiter nos clients, nous avons eu une mauvaise surprise : les statistiques que nous obtenions étaient fausses…

Après une recherche en profondeur, nous avons fini par en découvrir la cause : le séparateur de décimal.

Contre toute attente, et ce, malgré la norme du standard JSON, FileMaker Server renvoie des nombres formatés selon les paramètres du système. Or dans nos contrées, c’est la virgule alors que le standard JSON attend un point.

Résultat : tous les nombres décimaux sont ignorés par Tableau et les statistiques que vous obtenez sont faussées

Que faire ? Changer le format du système pour le forcer à renvoyer des nombres justes ? Cette option ne nous enchante guère, elle pourrait de plus avoir des conséquences inattendues.

Heureusement, nous sommes parvenu à trouver un moyen de contournement bien plus simple et efficace !

Tout se passe au niveau du connecteur FileMaker pour Tableau, dans un petit fichier javascript répondant ou doux nom de “fm_connector_util.js” que vous trouverez dans le dossier “/Library/FileMaker Server/Web Publishing/publishing-engine/node-wip/public/tableau/js”.

Dans ce fichier se cache une fonction qui permet de convertir à la volée les dates “FileMaker” dans un format de date compatible avec Tableau et il s’est avéré très facile d’étendre son champ d’action aux nombres !

En attendant un correctif officiel de la part de FileMaker nous avons décidé de partager ce fix avec la communauté par ce qu’il n’y a pas de raison pour que nous soyons les seuls à pouvoir utiliser Tableau en Europe !

Voici le fichier en question : fm_connector_util.js

Placez le simplement dans le dossier “FileMaker Server/Web Publishing/publishing-engine/node-wip/public/tableau/js” (remplacez le fichier existant), rechargez votre source de donnée dans Tableau et le tour est joué !

NB : Pensez à faire une copie de sauvegarde du fichier original avant d’appliquer le correctif !

 

English version

L’API PHP de FileMaker est elle en fin de vie ? C’est une question que l’on pourrait se poser depuis qu’une nouvelle technologie est apparue dans FileMaker Server 16 pour nous permettre de partager les données d’une base FileMaker au travers d’un site web: l’API REST. Cependant, bien que cette nouvelle API (encore en version beta – [EDIT : en version finale avec FileMaker 17]) apporte un vrai vent de fraîcheur et offre de belles perspectives d’évolution, elle n’en demeure pas moins limitée pour l’instant et moins adaptée à une architecture web classique où le serveur web occupe un rôle central.

Aussi, la publication XML couplée à l’API PHP de FileMaker reste encore à ce jour le meilleur moyen pour partager et utiliser une solution directement sur le Web.

Elle souffre malgré tout de certaines lacunes : développée pour être compatible avec PHP 4 à sa sortie (une version encore répandue à l’époque), l’API PHP originale (téléchargement) n’a quasiment pas évolué depuis (à part quelques corrections mineures).

Tous ceux qui l’ont utilisée, se rappellent certainement des nombreuses alertes indiquant l’utilisation des méthodes dépréciées dès lors qu’elles étaient exécutées avec une version plus récente de PHP. Bien que ces erreurs aient été corrigées depuis, l’avènement de PHP 7 les a malheureusement remises au goût du jour.

Ce manque d’évolution a rendu son code vétuste, il n’est plus du tout en phase avec les nouvelles méthodes de développement qui ont émergé ces dernières années dans l’univers de PHP, et de fait ce retard d’actualisation rend son intégration compliquée dans tout projet utilisant un framework ou un CMS “moderne”.

Une mise à jour de cette bibliothèque était devenue de plus en plus nécessaire pour assurer sa pérennité. Seulement voilà, bien que PHP ait encore de beaux jours devant lui au vu de ses améliorations régulières et de sa grande popularité, FileMaker a décidé de faire les yeux doux aux technologies plus en vogue actuellement, telles que les frameworks JavaScript. Inutile dès lors d’espérer une quelconque évolution de ce côté-là (la publication XML n’est et ne sera a priori jamais disponible sur FileMaker Cloud par exemple).

Il ne restait donc qu’une seule solution : retrousser ses manches et mettre les mains dans le cambouis afin de prodiguer une petite cure de jouvence à notre chère API PHP !

Méthodologie

Évidemment, avant de toucher à la moindre ligne de code, il fallait se plonger d’abord, tel un moine cistercien, dans une longue et approfondie étude du code source original, pour comprendre sa structure, son fonctionnement et ses particularités afin de bien saisir l’ampleur du chantier à venir.

Très vite, deux exigences se sont imposées : simplifier au mieux le code source (tout en essayant de l’optimiser), et le moderniser afin de le rendre conforme aux standards de développement actuels, notamment ceux recommandés par le groupe PHP-FIG, dans l’objectif d’assurer une meilleure interopérabilité avec la plupart des frameworks et CMS PHP modernes.

Côté simplification, les changements se sont portés principalement sur une nouvelle stratégie de gestion des erreurs et sur la réécriture d’une partie du code afin de respecter la norme PSR-2 (conventions d’écriture du code source).

La nouvelle gestion d’erreurs consiste à s’affranchir des tests conditionnels ponctuels au bénéfice d’une seule structure générale de test par exceptions, avec un bloc de type “try / catch” englobant les principales instructions de travail (voir un exemple de code plus bas). La méthode originale reste cependant toujours fonctionnelle afin d’assurer une compatibilité descendante.

Cette première étape terminée, il fallait maintenant consolider la compatibilité avec les versions les plus récentes de PHP et en tirer le meilleur parti pour moderniser au maximum le code.

Dès lors, concernant la modernisation du code source, l’ajout des espaces de noms, sur l’ensemble des classes de l’API, couplé à un système “d’auto-chargement”, comme le préconise la spécification PSR-4, se sont imposés, assurant de facto la compatibilité avec les frameworks PHP les plus en vogue du moment.

Cette technique a entraîné un changement en profondeur de la structure des fichiers, sans pour autant modifier le fonctionnement d’origine de l’API, et ce, dans le but de garantir une parfaite compatibilité avec les projets basés sur l’API-PHP de FileMaker originale.

S’ouvrir au reste du monde

Nous y étions ! l’API PHP de FileMaker était enfin modernisé ! Ne restait plus alors qu’à l’ouvrir au reste du monde libre !

En effet, depuis quelques années maintenant, les projets PHP se sont structurés autour d’une multitude de bibliothèques tierces, à l’instar de beaucoup d’autres langages tel que java, javascript, …

Afin de simplifier la gestion de ces multiples codes source et d’assurer leur mise à jour sans effort (le code étant maintenu par d’autres développeur), un outil désormais très populaire a été créé : Composer. Celui-ci permet de gérer, à l’aide d’un simple fichier de configuration (json) l’ensemble des bibliothèques tierces d’un projet, en assurant l’installation et la mise à jour.

De toute évidence, notre API se devait de rejoindre la communauté pour achever sa mutation, ce qui nécessita quelques adaptations non sans conséquences : cela a conduit à abandonner le fichier de configuration original de l’API (dans le monde de Composer, une bibliothèque tierce ne doit jamais être modifiée pour garder le bénéfice des mises à jour). Cela implique qu’il est désormais livré avec une configuration « par défaut », qu’il vous appartient de modifier au moment de son instanciation.

Evolutions

Notre nouvelle API fin prête, il nous tardait de l’intégrer dans un projet d’ampleur pour en mesurer son potentiel, ce qui fut rapidement le cas ! Un projet nécessitant l’emploi d’un Framework (yii2) s’étant rapidement présenté.

Ce premier galop d’essai a permis de mettre en lumière certaines lacunes qui n’étaient pas forcément apparues lors de la réécriture, notamment le besoin de faciliter le débogage lors des développements et d’améliorer la communication avec des bibliothèques tierces.

Ainsi, un certain nombre de nouvelles fonctionnalités ont été implémentées au fil de l’eau, dont voici une liste non exhaustive (certaines développées spécifiquement, d’autres issues des fonctions déjà existantes dans l’API-XML de FileMaker, mais non implémentées dans l’API-PHP de FileMaker d’origine) :

• Choix du format de date en entrée et sortie de l’API ;
• Prise en charge de la « pagination » lors de l’exécution d’un script ;
• Définition de globales à l’exécution d’une recherche ;
• Méthode permettant de récupérer la dernière requête (URL) envoyée au serveur FileMaker  (extrêmement utile pour le debogage en phase de développement);
• L’objet “Layout” peut désormais renvoyer le nom de la table source (en plus du nom de l’occurrence de table) via la propriété $layout->table, permettant une gestion plus simple des contextes d’exécution ;
• Méthode permettant la récupération d’une liste de valeurs associée à un champ sur un modèle (les listes peuvent ainsi être renommées sans impact sur votre site web).

Installation et configuration

Voici, en quelques lignes, les principales étapes pour installer et mettre en service cette nouvelle API-PHP de FileMaker.

Il y a deux méthodes d’installation de cette API :

1. Via la solution “Composer”, en ajoutant "airmoi/filemaker" : "*" à votre fichier de configuration ;
2. Manuellement en téléchargeant les dernières sources sur le site de GitHub dédié et en installant les fichiers décompressés dans votre projet : Dépot GitHub

Pour le chargement et l’activation de l’API, c’est très simple, il suffit d’inclure le fichier “autoload.php” qui se trouve à la racine du projet (facultatif en cas d’installation via Composer):
require ('/path/to/API/autoload.php');

Vous devez ensuite déclarer la classe à utiliser à l’aide de son espace de nom (l’autoloader se chargeant de trouver automatiquement les fichiers à charger pour assurer le bon fonctionnement de l’API) :
use airmoi\FileMaker\FileMaker;

Le fichier de configuration ayant disparu, deux méthodes sont disponibles pour configurer votre projet :

1. Utilisation de la méthode PHP de FileMaker : setProperty('name', $value), qui peut servir pour configurer individuellement les différents paramètres du projet ;
2. Utilisation d’un tableau de paramètres directement à la création de l’objet FileMaker, par exemple :
   new FileMaker($db, $host, $user, $pass, ['dateFormat' => 'd/m/Y'])
   permettant de configurer le projet en une seule instruction.

Voici un code d’exemple illustrant tout ceci :

[code language=”php”]
// Chargement de l’API
require_once (‘/path/to/API/autoload.php’);

// Définition de l’espace de noms
use airmoi\FileMaker\FileMaker;

// Réglage des options de configuration
$options = [
‘errorHandling’ => ‘default’,
‘locale’ => ‘fr’,
‘prevalidate’ => true,
‘dateFormat’ => ‘d/m/Y’,
];

// Création de l’objet FileMaker avec le tableau de paramètres
$fm = new FileMaker($db, $host, $user, $pass, $options);

// Récupération de la liste de tous les modèles et leur affichage
$layouts = $fm->listLayouts();
foreach ($layouts as $layout) {
echo $layout . ‘
‘;
}
[/code]

Exemples d’utilisation

Gestion des erreurs : l’ancienne méthode

[code language=”php”]
// Réglage des options de configuration
$options = [
‘errorHandling’ => ‘default’,
];

$fm = new FileMaker($db, $host, $user, $pass, $options);

// Récupération d’un modèle et test sur une éventuelle erreur
$layout = $fm->getLayout(‘sample’);
if (FileMaker::isError($layout)) {
echo "Error: " . $layout->getMessage();
exit;
}

// Execution de la requete
$result= $fm->newFindAnyCommand(‘sample’)->execute();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}

// Récupération d’un enregistrement
$record = $result->getFirstRecord();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}

// Modification de l’enregistrement
$record->setField(‘text_field’, str_repeat(‘a’, 51));
$record->commit();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}
[/code]

L’ancien système de gestion d’erreur s’obtient en réglant le paramètre “errorHandling” à la valeur “default”.
Comme on peut le constater, elle vous oblige à répéter vos contrôles pour pratiquement chaque instruction.

Gestion des erreurs : la technique des exceptions

[code language=”php”]
//Le mode de gestion par Exception est configuré par défaut
//il n’est donc pas nécessaire de le préciser dans les options
$fm = new FileMaker($db, $host, $user, $pass);

try {
// Récupération d’un modèle
$layout = $fm->getLayout(‘sample’);

// Récupération d’un enregistrement en 1 ligne
$record = $fm->newFindAnyCommand(‘sample’)->execute()->getFirstRecord();

// Modification de l’enregistrement
$record->setField(‘text_field’, str_repeat(‘a’, 51));
$record->commit();
} catch (FileMakerException $e) {
//Gestion des erreurs ayant pu survenir à n’importe quelle ligne
printf (‘Erreur %d : %s ‘, $e->getCode(), $e->getMessage());
}
[/code]

Comme vous pouvez le constater, la gestion d’erreur par exception via le bloc try/catch permet de réduire de façon considérable le nombre de lignes de code.
Toute sa logique peut être centralisée, ce qui simplifie la lecture du code, améliore sa fiabilité et sa maintenance.

Limiter les résultats d’un script

[code language=”php”]
$fm = new FileMaker($db, $host, $user, $pass);
$result = $fm->newPerformScriptCommand(‘sample’, ‘create sample data’, 50)
->setRange(5, 20)
->execute();

echo $result->getFetchCount() . ‘/’ . $result->getFoundSetCount();
[/code]

Désormais, avec cette nouvelle API, on peut demander quel intervalle de données récupérer. Par exemple, on peut demander d’avoir les données correspondant aux enregistrements de 5 à 25. Cela permet d’obtenir une pagination sur un résultat de script, ce qui était impossible auparavant

Définir une globale à l’exécution d’une requête

[code language=”php”]
$fm = new FileMaker($db, $host, $user, $pass);
$result = $fm->newFindCommand(‘sample’)
->setGlobal(‘global_field’, date(‘m/d/Y’))
->addFindCriterion(‘test_field’, 1)
->execute();

echo $result->getFetchCount() . " enregistrements trouvés.";
[/code]

Fonctionnalité très pratique, car elle permet désormais de définir une globale au moment de l’exécution d’une requête, ce qui vous permettra par exemple de récupérer, dans vos résultats, des données liées au travers d’une globale.

Conclusion

Comme expliqué au début de l’article, l’API PHP de FileMaker avait bien besoin d’un sacré coup de jeune pour s’adapter à l’évolution des technologies les plus récentes, notamment concernant l’interaction avec les frameworks PHP modernes.

Cette réécriture a nécessité de nombreuses heures de travail et d’innombrables tests. Le résultat est plus qu’encourageant puisque cette nouvelle version est désormais utilisée quotidiennement en production sur plusieurs projets professionnels gérés par l’équipe de 1-more-thing.

Mais, bien qu’elle soit en l’état assez stable et aboutie pour être utilisée en production, cette réécriture n’est cependant pas encore terminée, bien d’autres améliorations sont en cours et d’autres à prévoir. Si vous souhaitez contribuer à son évolution, vous êtes évidemment les bienvenus : Dépot GitHub.

Un grand merci à tous ceux qui ont participé, directement ou indirectement, à la réalisation de ce projet, et un remerciement tout particulier à Matthias Kühne pour toutes ses contributions.

Version française

Is the FileMaker PHP API at end of life? This is a question that could arise since a new technology appeared in FileMaker Server 16 to allow us to share data from a FileMaker database through a website: the REST API. However, although this new API (still in beta version – [EDIT: in final version with FileMaker 17]) brings a real wind of freshness and offers beautiful prospects of evolution, it remains nonetheless limited for the instant and less adapted to a classic web architecture where the web server occupies a central role.

Therefore XML publishing combined with the FileMaker PHP API is still often the best way to share and use a solution directly on the Web.

It still suffers from some shortcomings: developed to be compatible with PHP 4 at its release (a version still widespread at the time), the original PHP API (download) has hardly changed since (except for some minor corrections) ).

Anyone who has used it, certainly remember many alerts indicating the use of deprecated methods as soon as they were run with a newer version of PHP. Although these errors have since been corrected, the advent of PHP 7 has unfortunately brought them up to date.

This lack of evolution has made its code obsolete, it is not at all in step with the new development methods that have emerged in recent years in the PHP universe, and in fact this update delay makes its integration complicated in any project using a framework or a “modern” CMS.

An update of this library had become more and more necessary to ensure its durability. But here, although PHP still has a bright future ahead of time given its steady improvements and popularity, FileMaker has decided to take a good look at the more popular technologies such as JavaScript frameworks. No need therefore to hope for any evolution on this side (the XML publication is and will never be available on FileMaker Cloud for example).

So there was only one solution: roll up his sleeves and put his hands in the grease to give a little makeover to our dear PHP API!

Methodology

Obviously, before touching any line of code, one had to dive first, like a Cistercian monk, into a long and thorough study of the original source code, to understand its structure, its functioning and its particularities in order to grasp well the magnitude of the upcoming work.

Very quickly, two requirements were imposed: simplifying the source code as much as possible (while trying to optimize it), and modernizing it to bring it into line with current development standards, especially those recommended by the PHP-FIG group, in the goal of ensuring better interoperability with most modern PHP frameworks and CMSs.

On the simplification side, the changes mainly focused on a new error management strategy and rewriting part of the code in order to comply with the PSR-2 standard (source code writing conventions).

The new error handling is to overcome the occasional conditional tests for the benefit of a single general test structure by exception, with a block of type “try / catch” encompassing the main work instructions (see a sample code lower). The original method still remains functional, however, to ensure backward compatibility.

This first step was completed, it was now necessary to consolidate compatibility with the most recent versions of PHP and make the most of it to modernize the code as much as possible.

Therefore, concerning the modernization of the source code, the addition of namespaces, on all the classes of the API, coupled with a “self-loading” system, as recommended by the PSR-4 specification, have imposed themselves, ensuring de facto compatibility with the most popular PHP frameworks of the moment.

This technique has resulted in a profound change in the file structure, without changing the original operation of the API, in order to ensure full compatibility with projects based on the API-PHP of Original FileMaker.

Open to the World

We were there ! the PHP API of FileMaker was finally modernized! Then remained open to the rest of the free world!

Indeed, for some years now, PHP projects have been structured around a multitude of third-party libraries, like many other languages ​​such as java, javascript, …

In order to simplify the management of these multiple source codes and to ensure their updating without effort (the code being maintained by other developers), a very popular tool has now been created: Composer. It allows to manage, with the help of a simple configuration file (json) all the third libraries of a project, ensuring the installation and the update.

Obviously, our API had to join the community to complete its mutation, which necessitated some adaptations not without consequences: that led to abandon the original configuration file of the API (in the world of Composer, a third library should never be modified to keep the benefit of updates). This implies that it is now delivered with a “default” configuration, which you must modify at the moment of instantiation.

Evolutions

Our new API ready, we were eager to integrate it into a large project to measure its potential, which was quickly the case! A project requiring the use of a Framework (yii2) was quickly presented.

This first test run highlighted some deficiencies that did not necessarily appear during the rewrite, including the need to facilitate debugging during development and improve communication with third-party libraries.

Thus, a certain number of new features have been implemented over the water, of which here is a non-exhaustive list (some developed specifically, others resulting from functions already existing in FileMaker API-XML, but not implemented in the original FileMaker PHP-API):

• Choice of date format input and output of the API;
• Support for “paging” when running a script;
• Definition of global at the execution of a search;
• Method to retrieve the last request (URL) sent to the FileMaker server (extremely useful for debugging in the development phase);
• The “Layout” object can now return the name of the source table (in addition to the name of the table instance) via the $ $layout->table property, allowing easier management of execution contexts;
• Method for retrieving a list of values ​​associated with a field on a model (lists can be renamed without impact on your website).

Installation and configuration

Here are some of the main steps to install and implement this new FileMaker PHP API.

There are two methods of installing this API:

1. Via the “Composer” solution, adding "airmoi/filemaker" : "*" to your configuration file;
2. Manually by downloading the latest sources from the dedicated GitHub website and installing the uncompressed files in your project: GitHub Repository

For the loading and the activation of the API, it is very simple, it is enough to include the file “autoload.php” which is at the root of the project (optional in case of installation via Composer):
require ('/path/to/API/autoload.php');

You must then declare the class to use using its namespace (the autoloader is responsible for automatically finding the files to load for the proper functioning of the API):
use airmoi\FileMaker\FileMaker;

Since the configuration file was removed, two methods are available to configure your project:

1. Using the FileMaker PHP method: setProperty('name', $value), which can be used to individually configure the different parameters of the project;
2. Use a parameter array directly when creating the FileMaker object, for example: new FileMaker($db, $host, $user, $pass, ['dateFormat' => 'd/m/Y']) to configure the project in one single instruction.

Here is an example code illustrating all this:

[code language=”php”]
// Load the API
require_once (‘/path/to/API/autoload.php’);

// define name space
use airmoi\FileMaker\FileMaker;

// configuration options
$options = [
‘errorHandling’ => ‘default’,
‘locale’ => ‘fr’,
‘prevalidate’ => true,
‘dateFormat’ => ‘d/m/Y’,
];

// FileMaker object w/ parameter array
$fm = new FileMaker($db, $host, $user, $pass, $options);

// List all layouts and view as types
$layouts = $fm->listLayouts();
foreach ($layouts as $layout) {
echo $layout . ‘
‘;
}
[/code]

Usage

Error trapping: the ‘old’ way

[code language=”php”]
// Configuration
$options = [
‘errorHandling’ => ‘default’,
];

$fm = new FileMaker($db, $host, $user, $pass, $options);

// Get a layout and test
$layout = $fm->getLayout(‘sample’);
if (FileMaker::isError($layout)) {
echo "Error: " . $layout->getMessage();
exit;
}

// Execute query
$result= $fm->newFindAnyCommand(‘sample’)->execute();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}

// Get a record
$record = $result->getFirstRecord();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}

// Modify a record
$record->setField(‘text_field’, str_repeat(‘a’, 51));
$record->commit();
if (FileMaker::isError($record)) {
echo "Error: " . $record->getMessage();
exit;
}
[/code]

The old error management system is obtained by setting the “errorHandling” parameter to the “default” value.
As you can see, it forces you to repeat your controls for virtually every instruction.

Error Management: The Exception Method

[code language=”php”]
// Exception mode is configured by default
// no need to specify it
$fm = new FileMaker($db, $host, $user, $pass);

try {
// Try to get a layout
$layout = $fm->getLayout(‘sample’);

// Get a record (in 1 line)
$record = $fm->newFindAnyCommand(‘sample’)->execute()->getFirstRecord();

// Modify record
$record->setField(‘text_field’, str_repeat(‘a’, 51));
$record->commit();
} catch (FileMakerException $e) {
// Trap errors that can have occurred on any line
printf (‘Error %d : %s ‘, $e->getCode(), $e->getMessage());
}
[/code]

As you can see, exception handling via the try / catch block can significantly reduce the number of lines of code.
All its logic can be centralized, which simplifies the reading of the code, improves its reliability and its maintenance.

Limit the results of a script

[code language=”php”]
$fm = new FileMaker($db, $host, $user, $pass);
$result = $fm->newPerformScriptCommand(‘sample’, ‘create sample data’, 50)
->setRange(5, 20)
->execute();

echo $result->getFetchCount() . ‘/’ . $result->getFoundSetCount();
[/code]

Now, with this new API, you can ask which data interval to retrieve. For example, you can request to have the data corresponding to the records from 5 to 25. This allows to obtain a pagination on a script result, which was impossible before.

Set a global field on executing a query

[code language=”php”]
$fm = new FileMaker($db, $host, $user, $pass);
$result = $fm->newFindCommand(‘sample’)
->setGlobal(‘global_field’, date(‘m/d/Y’))
->addFindCriterion(‘test_field’, 1)
->execute();

echo $result->getFetchCount() . " enregistrements trouvés.";
[/code]

Very handy feature because it now allows to define a global field at the time of the execution of a query, which will allow you for example to recover, in your results, related data through a global field.

Conclusion

As explained at the beginning of the article, FileMaker’s PHP API really needed a fresh start to adapt to the evolution of the latest technologies, especially regarding the interaction with modern PHP frameworks.

This rewriting required many hours of work and countless tests. The result is more than encouraging as this new version is now used daily in production on several professional projects managed by the 1-more-thing team.

But, although it is in the stable and mature state to be used in production, this rewrite is not yet finished, many other improvements are in progress and others to predict. If you want to contribute to its evolution, you are obviously welcome: GitHub Repository.

Many thanks to all those who participated, directly or indirectly, in the realization of this project, and a special thanks to Matthias Kühne for all his contributions.