Genèse

Symfony c'est vraiment un framework cool. Ca permet d'accélérer et d'automatiser pas mal de tâches de développement. Mais bon, dans le cas d'une API on va pas se le cacher, il reste encore beaucoup de redondance. Créer une entité, créer son controller, rajouter les routes, créer les formulaires associés... C'est long, c'est répétitif, et on perd en visibilité. Pour au final faire toujours la même chose : stocker puis manipuler de la donnée. 

Et si je vous dis que maintenant, avec simplement 3 fichiers de configs YAML et en quelques dizaines de minutes, vous pouvez paramétrer et créer entièrement votre API ?

Généralité et avancement

Avec ce bundle, il vous est permis de :

• gérer une base de données modulaire, avec la possibilité de rajouter des tables ou des propriétés aux tables
• valider les données entrantes, via des formulaires mais aussi des "états de validation"
• activer ou désactiver une méthode HTTP sur une entité
• autoriser un utilisateur (ou un groupe d'utilisateur) de manipuler une donnée

Github du projet

Si vous besoin de plus d'informations, le bundle et son readme sont dispos ici : 

https://github.com/deozza/Philarmony

N'hésitez pas à faire mumuse avec et à me faire vos retours ! Est-ce que vous utiliserez ce genre de solution, quels seraient pour vous ses avantages et ses inconvénients, est-ce que le code pourrait être amélioré...

-
Edité par DeozzaMetalmusic 6 mai 2019 à 17:10:18

Hello,

Projet qui peut m'être bien utile

J'ai commencé à tester, il a fallu que je modifies 2 des fichiers yaml pour que l'installation fonctionne (juste une histoire de / et \)

services: 
    Deozza\PhilarmonyBundle\Controller\: ##finir par un \
      resource: '@DeozzaPhilarmonyBundle/Controller' ## modifier \ par /
      tags: ['controller.service_arguments']
      
    Deozza\PhilarmonyBundle\Repository\: ##finir par un \
      resource: '@DeozzaPhilarmonyBundle/Repository'  ## modifier \ par /
      tags: ['doctrine.service_entity'] 

philarmony_controllers:
    resource: '@DeozzaPhilarmonyBundle/Controller'  ## modifier \ par /
    type: annotation
    prefix: /

je continue les tests

Edit : pour les utilisateurs de MariaDB, il faut minimum la version 10.2

Xavier

-
Edité par QZIG 7 mai 2019 à 14:25:55

Ah oui exact pour la config. C'est quelque chose que j'ai corrige sur l'appli de demo mais pas dans la doc. Je règle ca au plus vite. 

Pour la base de donnees, pour l'instant a cause des fonctions de parsing de json, c'est compatible uniquement avec mysql (a partir de la v5.7).  Pour l'instant je vais laisser vivre la v1 du bundle. Mais je pense que je vais faire une v1.1 et virer mysql pour utiliser mongodb ou postgre ou sqlite. Bref un sgbd plus adapté au traitement du JSON

Mise à jour du 15/05/2019 - V1.2

Bonjour tout le monde ! Oui je sais ça ne fait pas une semaine que le bundle est disponible et il y a déjà une v1.2. Quelques fonctionnalités ont été rajoutées, et d'autres ont été améliorées !

Modification des nœuds des fichiers de configuration

Avec les nouvelles fonctionnalités à gérer, certains nœuds de configurations ont été ajoutés et d'autres ont été modifiés. Afin de rendre votre application compatible avec la dernière version de Philarmony, je vous encourage à mettre à jour vos fichiers YAML en suivant les exemples de la documentation:

https://github.com/deozza/Philarmony/blob/master/src/Resources/documentation/DatabaseSchema/ENTITY.md

https://github.com/deozza/Philarmony/blob/master/src/Resources/documentation/DatabaseSchema/PROPERTY.md

Base de données

La base de données est toujours compatible uniquement avec mysql, à partir de la version 5.7. Je n'ai pas encore pu faire la migrations vers mongodb. 

Un parser de configuration plus efficace

Dans le but de rendre le parser plus robuste (et d'éviter des erreurs 500), Philarmony va d'abord scanner le fichier de configuration et vérifier que les nœuds requis par le système sont biens présents. Si ce n'est pas le cas, une erreur 400 est renvoyée.

Contraintes sur des entités imbriquées

Il est à présent possible d'appliquer des contraintes sur des entités imbriquées directement depuis celles-ci (et non pas depuis l'entité mère). 

Meilleure pagination 

La pagination de la requête GET /api/entity/{entity_name} a été améliorée. En ce qui concerne les filtres, il est à présent possible d'appliquer différents opérateurs (supérieur à, inférieur à, égal à, ...).

Il est également possible de trier les résultats de cette requête en fonction d'une ou de plusieurs paramètres.

Ce paragraphe de la documentation explique comment faire:

https://github.com/deozza/Philarmony/blob/master/src/Resources/documentation/DatabaseSchema/ENTITY.md#get-all-the-entries-of-a-kind

Gestion des événements

Philarmony est à présent capable de gérer les événements Symfony grâce à l'EventDispatcherInterface. Les événements sont exécutés à la fin d'une requête réussie, avant de persister l'entité. Vous n'avez qu'à rajouter le nom de l'événement dans la configuration d'une entité et à lé développer dans votre application.

Pour en savoir davantage sur les événements, vous pouvez lire cette documentation:

https://github.com/deozza/Philarmony/blob/master/src/Resources/documentation/DatabaseSchema/ENTITY.md#launch-post-scripts

Contraintes avancées

Si les contraintes que vous voulez appliquer sur une entité sont complexes et ne peuvent pas être gérées avec la configuration, vous pouvez les développer vous-même et les stocker dans votre application. C'est ce que j'ai appelé des Rules (pour règles de gestion). Les Rules sont appliquées avant les Constraints (les contraintes écrites dans la configuration). Lorsqu'une Rule n'est pas respectée, l'entité n'est pas persistée et une réponse 409 est envoyée.

Pour en savoir plus, vous pouvez lire ceci:

https://github.com/deozza/Philarmony/blob/master/src/Resources/documentation/RuleManager/CONFLICTRULE.md

-
Edité par DeozzaMetalmusic 15 mai 2019 à 10:28:48

Mise à jour du 03/06/2019 - V2.0

Salut tout le monde ! Une nouvelle release stable de Philarmony est sortie et remplace la précédente. Fondamentalement elle ne change pas grand chose au niveau des fonctionnalités. C'est davantage dans la philosophie du bundle que des modifications ont eu lieu.

On ne pourrrait plus vraiment parler de bundle Philarmony d'ailleurs. En effet, je compte transformer Philarmony et en faire une surcouche complète via plusieurs bundle.

PhilarmonyCoreBundle

PhilarmonyBundle est devenu PhilarmonyCoreBundle. Il est indépendant et propose la fonctionnalité clef du système : fournir un back-end dynamique et configurable via des fichiers YAML. Son contenu a été éclaté pour assurer une meilleure maintenabilité et facilité l'ajout de fonctionnalités.

Si vous utilisiez Philarmony dans sa version 1.2, quelques ajustements sont à prévoir.

PhilarmonyUserBundle

Dans l'optique de proposer une gestion adéquate des utilisateurs, un bundle est en cours de développement. Il s'accorde parfaitement à PhilarmonyCoreBundle mais peut aussi être utilisé indépendamment. Il proposera une gestion d'utilisateurs similaire à ce que faisait FOSUserBundle. En étendant la classe User fournie par le système, vous pourrez lui rajouter des propriétés. Les formulaires correspondant seront automatiquement mis à jours.

-
Edité par DeozzaMetalmusic 3 juin 2019 à 14:53:48

Oui je connais Je l'avais essayé il y a quelques années sans trop rentrer dans les détails. J'ai récemment relu leur documentation et me suis aperçu que le bundle que je développais lui ressemble beaucoup. J'ai quand même continué à développer Philarmony pour le sport, pour savoir si j'en étais capable, et surtout pour savoir ce que je pourrais apporter en plus. Notamment le système d'état et de validation dynamique des données, qui je crois n'est pas présent dans ApiPlatform.