- PHP 76.2%
- JavaScript 11.7%
- HTML 7.1%
- CSS 4%
- Makefile 0.5%
- Other 0.3%
| .githooks | ||
| features | ||
| public | ||
| resource | ||
| sql | ||
| vendor | ||
| views | ||
| .DS_Store | ||
| .ftpconfig | ||
| .gitattributes | ||
| angler | ||
| ANNOTATIONS.md | ||
| ChangeLog.md | ||
| composer.json | ||
| Makefile | ||
| package.ini | ||
| PARAM.md | ||
| README.md | ||
ICEMAN
Introduction
ICEMAN est l'API centrale majeure de l'éco-système de Dubbing Brothers.
Propulsé par Restler (version 3.0.0) et par RedBeanPHP (version 3.x), ICEMAN permet la gestion API de plusieurs applications dont :
- Lantern ;
- VoiceMatch ;
- Magnéto ;
- Saloon ;
- Et d'autres en court de développement.
Installation
Pour développer sur ICEMAN en local, il suffit de récupérer le repo et d'avoir un environnement LAMP.
Restler
Une fois récupérer, l'installation de Restler sera peut-être nécessaire (https://github.com/Luracast/Restler)(autrement la copie du dossier vendor depuis les serveurs marchent (http://10.0.1.28/var/www/restler)).
Base de données
Pour faire fonctionnner l'API, la base de données devra être créée. Pour rester en accord avec nos serveurs de pré-prod et de prod, il est conseiller de nommer la base "central-api".
Remplissez ensuite la base via le schéma SQL + données du server de pré-prod (10.0.1.28 : identifiants à demander). Renseignez un utilisateur pour la BDD puis modifier dans le fichier "index.html", dans le dossier "central-api", cette ligne :
R::setup('mysql:host={SERVEURLOCAL};dbname=central-api', '{USERNAME}', '{MOTDEPASSE}');
Remplacer {SERVEURLOCAL} par votre localhost, {USERNAME} par le nom de l'utilsateur BDD et {MOTDEPASSE} par le mot de passe de l'uitilisateur.
**⚠️ IL EST IMPÉRATIF DE VÉRIFIER QUE LE FICHIER EST BIEN EXCLU LORS DE VOTRE COMMIT ⚠️ **
Vérification
Vous pourrez vérifier si l'API fonctionne bien en accédant à cette page : http://localhost:8888/restler/public/central-api/explorer/index.html
Si la page affiche les endpoints publiques celà veut dire que la configuration c'est bien passé.
Troubleshooting
ERREUR
Il se peut que la page explorer affiche une erreur du style "404 : ../resource.json not found".
SOLUTION
Télécharger depuis le serveur le dossier "central-api" et le remplacer dans votre repo. Bien vérifier que le dossier soit à jour sur Github ET sur le serveur de récupération.
ERREUR
Il se peut que l'installation de Restler ait raté et que le dossier vendor ne soit pas correctement initialisé.
SOLUTION
Une solution simple est de télécharger le dossier vendor depuis le serveur de pré-prod (10.0.1.28) et de le copier dans votre répoertoire locale.
Utilisation de l'API locale
Si la configuratrion s'est bien déroulée, vous pouvez maintenant passer à la configuration de vos applications. Faites pointer vos fichier de configuration vers l'API locale et tout devrait bien marcher.
Concernant la création d'un compte utilisateur, la solution la plus simple sera de créer un compte sur le serveur de pré-prod et de récupérer la ligne correspondante dans votre BDD locale.
Développement
Lors du développement, nous utiliserons la méthode de Git Flow avec cette arborescence :
-
Une branche « master » o C’est la branche principale, utilisée pour la mise en production.
-
Une branche « develop » o La branche secondaire, c’est la branche recevant le code des branches « features ».
-
Plusieurs branches « features »
o Il existe une branche «feature» par récits utilisateurs lors du sprint en cours.
-
Une branche « release »
o La branche «release» intervient à la fin d’un sprint. C’est à partir d’elle que la recette se fera.
-
Une branche « hotfix » o Cette branche est ici pour corriger les bugs critiquent observés sur la branche « master ».
Production
Dans l'environnement de production, les constantes suivantes dans le config.php devraient être mises a true:
- FREEZE_DATABASE
- RESTLER_PRODUCTION_MODE
En production, le projet fera appel aux hooks GIT définis dans .githooks. Cela permet par exemple
de nettoyer les fichiers de cache lors de l'introduction de nouveaux endpoints.
Afin d'etre pris en compte, executer :
git config core.hooksPath .githooks
Améliorations futures
Utilisation de la librairie GitAutoDeploy afin de pousser automatiquement les modifications sur les serveurs.
Comet
Comet- Settings
In Comet there are settings in config.php and DB.
The only setting in config is about the path where to save the signatures and contracts. The setting CONTRACT_FOLDER is pointing to this path. Inside there must be 3 folders: "static", "signatures", "contracts".
In "static", are all the templates/images used in process of generating the contracts. If you need to change the template for CC/CICF/FDP/Planning probably you need to change\add a file here. In "contracts", all signed contracts are stored here. In "signatures", every signature used in the contract is stored here as image.
The settings in DB, as any other application, has a constant defined in SettingService.php. For Comet we have public static $Setting_Comet_Contract_Font_Size = 54; public static $Setting_Comet_Contract_Font_Name = 55; public static $Setting_Comet_Director_Signature_Image_Name = 56; public static $Setting_Comet_Notification_Email_Group_FR = 57; public static $Setting_Comet_Notification_Contract_Message_Subject = 58; public static $Setting_Comet_Notification_Contract_Message_Body = 59; public static $Setting_Comet_Notification_From_Address_FR = 60; public static $Setting_Comet_Notification_End_Recording_Subject = 61; public static $Setting_Comet_Notification_End_Recording_Body = 62;
The name, as well as the description in DB, is enough to understand the meaning of them.
Comet - General templates
The templates in folder "static", are not statically selected, but are queried from DB, based on a search criteria, which includes client+product type+language. The table is contract_export_template. The function which selectes the template is ContractService->getExportTemplatesByFilters.
Comet - FDP template
The FDP(feuille de presence) template is store in "static" folder, in fdp.html. As stated before, it is selected from contract_export_template. The html is transformed into PDF using PhpSpreadsheet library. There are many restrictions, since the library supports only basic html stuff, please check the section below.
Comet - Contract templates
Contract templates are stored in DB in contract_template. Here there is a small description. The templates are HTML, but not all situations are possibile. You can chheck the page of PhpSpreadsheet for more info. The most important is that inside of tables, you cannot use div's or block elements, so no complicated html, but you can use the style(bold, itali etc.). PhpSpreadsheet knows how to shrink the content of a div to fit in a page, basically using a div with absolute position. When generating the pdf, the html for every page of the contract, is wrapped around an absolute div, so it doesn't flow on a different page. If you want to add multiple pages, is possibile inside of Comet, in the contract template page.
Placeholder replacing
Any template can contain placeholder, which are replaced with actual information. There is a function that I created in MailsFunctions.php, that is because first I used it for email. The replacement process takes complex expression, so you can use array in array, check parameter for empty string / false value, or if not empty/false. The repeaters takes a third parameter, which defines what to display for the last element in array. Here are some examples:
{{VariableName}} , in php you have something like data["VariableName"] = VariableValue, so the whole "{{VariableName}}" will be replaced with "VariableValue". {{VariableName?expression}}, this checkes if VariableValue is not empty and not false, then start replacing all placeholders in "expression". {{VariableName!expression}}, this checkes if VariableValue is empty or false, if so then replaces all placeholders in "expression". {{VariableName|expression|last_array_expression}}, that defines the iteration of an array, and what to display for every item. The "last_array_expression" is applied for the last item in the array. The "last_array_expression" is optional. The VariableName is a simple array of associative arrays. The "expression" and "last_array_expression" can contain only keys from the associative array. An example:
[ ["name" => "John", "age" => 26"], ["name" => "Valentin", "age" => 99] ]
The "expression" should look something like "Name is {{name}} and age is {{age}}".