Bonjour,
Je voulais faire un petit poste pour partager mon dernier projet open source. Il s'agit d'un framework js (côté client).
Pourquoi faire un nouveau framework alors qu'il y en a déjà plein? La raison est assez simple. Je me suis rendu compte d'une chose, et que j'ai vu reproché par d'autres développeurs, est le manque de structure de tous les frameworks. Par là je veux dire qu'aucun ne vous dit comment bien structurer votre code et on finit souvent par avoir des variables un peu dans tous les sens.
De ce constat je me suis poser la question comment faire mieux. Alors plutôt que chercher de nouvelles façons d'écrire un framework, je me suis inspiré de ce qui est fait côté serveur (je suis dev php à la base) étant donné que les technos sont plus matures. J'ai donc pris exemple sur mon framework préféré: Symfony2.
L'autre intérêt que j'ai vu avec cette approche est qu'il peut être intéressant de permettre aux dev front et back d'avoir les mêmes notions de conceptions d'applications. Et faciliter l'accès au javascript pour un dev back ou vice versa.
Cette semaine j'ai donc publié la version 1.0 (après un an de dev) de ce framework. Au final les grands composants du framework sont:
* stockage de données (similaire à doctrine)
* conteneurs de services (similaire au composant DependencyInjection de sf2)
* validation de données (api similaire à celle de sf2)
* gestion de formulaire (api similaire à celle de sf2)
* routage
* gestion de vues
* contrôleurs
On retrouve également la même notion de bundle que dans Symfony2.
Autre point de la philosophie de Symfony2 que j'ai voulu conserver est le fait que quasiment chaque composant peut être utilisé en dehors du framework.
Vous trouverez une démo, tuto et tout le code ici: http://github.com/Baptouuuu/Sy
Que pensez vous d'une telle approche pour construire un framework?
Modifié par Tony Monast (17 Oct 2014 - 14:34)
Je voulais faire un petit poste pour partager mon dernier projet open source. Il s'agit d'un framework js (côté client).
Pourquoi faire un nouveau framework alors qu'il y en a déjà plein? La raison est assez simple. Je me suis rendu compte d'une chose, et que j'ai vu reproché par d'autres développeurs, est le manque de structure de tous les frameworks. Par là je veux dire qu'aucun ne vous dit comment bien structurer votre code et on finit souvent par avoir des variables un peu dans tous les sens.
De ce constat je me suis poser la question comment faire mieux. Alors plutôt que chercher de nouvelles façons d'écrire un framework, je me suis inspiré de ce qui est fait côté serveur (je suis dev php à la base) étant donné que les technos sont plus matures. J'ai donc pris exemple sur mon framework préféré: Symfony2.
L'autre intérêt que j'ai vu avec cette approche est qu'il peut être intéressant de permettre aux dev front et back d'avoir les mêmes notions de conceptions d'applications. Et faciliter l'accès au javascript pour un dev back ou vice versa.
Cette semaine j'ai donc publié la version 1.0 (après un an de dev) de ce framework. Au final les grands composants du framework sont:
* stockage de données (similaire à doctrine)
* conteneurs de services (similaire au composant DependencyInjection de sf2)
* validation de données (api similaire à celle de sf2)
* gestion de formulaire (api similaire à celle de sf2)
* routage
* gestion de vues
* contrôleurs
On retrouve également la même notion de bundle que dans Symfony2.
Autre point de la philosophie de Symfony2 que j'ai voulu conserver est le fait que quasiment chaque composant peut être utilisé en dehors du framework.
Vous trouverez une démo, tuto et tout le code ici: http://github.com/Baptouuuu/Sy
Que pensez vous d'une telle approche pour construire un framework?
Modifié par Tony Monast (17 Oct 2014 - 14:34)
