Merci pour les liens, quand je disais que ça avait déjà été fait. J'ai regardé vite fait les présentations/tutoriels et je note les points suivant :
- Php 5 : Je suis encore en PHP 4 chez mon hébergeur, et je n'ai pas l'intention de changer. Je ne ressens de toutes façons aucun besoin impérieux de passer au php5 pour le moment.
- Pour les bases de données, je modélise le critère de recherche comme un ensemble de critère -le tri est un critère de recherche possible-, et je peux générer différentes requêtes SQL en fonction de ces valeurs (critères multiples, test complexes avec groupage de conditions, utilisation des différents opérateurs, critères exclusifs, tri du resultat selon plusieurs colonnes avec un sens individualisé), je peux spécifier à l'instanciation de la classe principale le préfixe des tables et des colonnes, ce qui me permet de réutiliser le schéma dans la même table/base, ou de créer les tables en changeant les nom prévus par simple rajout d'un préfixe (mélange d'application web utilisant des nom de tables qui se recoupent, c'est du vécu). Bref, symfony ne fait pas tout ce que je veux avoir il me semble.
En revenche, je ne gère -encore- pas la création des tables, notamment à cause de la possibilité de dupliquer le schéma des tables (exemple type et réel que j'ai en tête, chaque table modélise un type de contenu différent, avec des colonnes communes -modèle de base utilisé pour la gestion et l'affichage général des contenus- et des colonnes spécifique voire des table filles -modèles supplémentaires-).
- J'ai une bonne expérience de xml/xslt, je n'ai pas le temps d'apprendre un nouveau langage aussi simple soit-il, cependant, rien n'empêche de rajouter ultérieurement une surcouche yaml->xml, par exemple.
- je ne veux pas passer en paramètre le nom d'une valeur à récupérer dans le request, j'encapsule ce qui est pour moi un détail d'implémentation dans mon "RequestProcessor" (permet de faire évoluer les noms utilisé pour la transmission des variables sans impact pour le reste de l'application) ==> $this->getRequestParameter('id') est à priori superflu, je ne vois pas la valeur ajoutée par rapport à un $_REQUEST['id'], et je ne veux pas savoir que la variable s'appelle 'id', car rien ne garanti qu'on continuera d'utiliser ce nom pour la transmission.
- de même, je veux isoler mon application des détails concernant les urls, toujours pour parer aux changements de scripts, voire de technologie (url classiques ou smart urls couplé à mod_rewrite), pour la même fonctionnalité, avec les mêmes paramètres. Ce que ne propose pas symphony apparemment.
Bref, en oubliant les prérequis techniques, et le fait que je mène ma propre réflexion, symfoni ne répond pas à tous mes besoins, donc pour mes projets perso, je continuerai a défricher ma voie.
Mais je ferais remarquer que :
- rien ne m'empêchera, si je veux passer à symfony -ou à autre chose-, d'utiliser mes outils pour générer le code que Symphony ne génèrera pas et que j'estimerai nécessaire. J'ai aussi conçu mes outils dans ce but (pallier aux manques d'un framework).
- je ne cherche pas à faire un truc tout intégré, mais une série d'outils indépendants (cf point précedent), pouvant éventuellement être utilisé ensemble. Les outils intégrés que je pourrait proposer par la suite ne sauraient être que des exemples de mise en oeuvre, même si ces exemples seront réutilisables.
[^] # Re: Ou alors on peut utiliser symfony ...
Posté par David Sporn . En réponse au journal Mise à disposition de mes outils pour générer du code PHP. Évalué à 4.
- Php 5 : Je suis encore en PHP 4 chez mon hébergeur, et je n'ai pas l'intention de changer. Je ne ressens de toutes façons aucun besoin impérieux de passer au php5 pour le moment.
- Pour les bases de données, je modélise le critère de recherche comme un ensemble de critère -le tri est un critère de recherche possible-, et je peux générer différentes requêtes SQL en fonction de ces valeurs (critères multiples, test complexes avec groupage de conditions, utilisation des différents opérateurs, critères exclusifs, tri du resultat selon plusieurs colonnes avec un sens individualisé), je peux spécifier à l'instanciation de la classe principale le préfixe des tables et des colonnes, ce qui me permet de réutiliser le schéma dans la même table/base, ou de créer les tables en changeant les nom prévus par simple rajout d'un préfixe (mélange d'application web utilisant des nom de tables qui se recoupent, c'est du vécu). Bref, symfony ne fait pas tout ce que je veux avoir il me semble.
En revenche, je ne gère -encore- pas la création des tables, notamment à cause de la possibilité de dupliquer le schéma des tables (exemple type et réel que j'ai en tête, chaque table modélise un type de contenu différent, avec des colonnes communes -modèle de base utilisé pour la gestion et l'affichage général des contenus- et des colonnes spécifique voire des table filles -modèles supplémentaires-).
- J'ai une bonne expérience de xml/xslt, je n'ai pas le temps d'apprendre un nouveau langage aussi simple soit-il, cependant, rien n'empêche de rajouter ultérieurement une surcouche yaml->xml, par exemple.
- je ne veux pas passer en paramètre le nom d'une valeur à récupérer dans le request, j'encapsule ce qui est pour moi un détail d'implémentation dans mon "RequestProcessor" (permet de faire évoluer les noms utilisé pour la transmission des variables sans impact pour le reste de l'application) ==> $this->getRequestParameter('id') est à priori superflu, je ne vois pas la valeur ajoutée par rapport à un $_REQUEST['id'], et je ne veux pas savoir que la variable s'appelle 'id', car rien ne garanti qu'on continuera d'utiliser ce nom pour la transmission.
- de même, je veux isoler mon application des détails concernant les urls, toujours pour parer aux changements de scripts, voire de technologie (url classiques ou smart urls couplé à mod_rewrite), pour la même fonctionnalité, avec les mêmes paramètres. Ce que ne propose pas symphony apparemment.
Bref, en oubliant les prérequis techniques, et le fait que je mène ma propre réflexion, symfoni ne répond pas à tous mes besoins, donc pour mes projets perso, je continuerai a défricher ma voie.
Mais je ferais remarquer que :
- rien ne m'empêchera, si je veux passer à symfony -ou à autre chose-, d'utiliser mes outils pour générer le code que Symphony ne génèrera pas et que j'estimerai nécessaire. J'ai aussi conçu mes outils dans ce but (pallier aux manques d'un framework).
- je ne cherche pas à faire un truc tout intégré, mais une série d'outils indépendants (cf point précedent), pouvant éventuellement être utilisé ensemble. Les outils intégrés que je pourrait proposer par la suite ne sauraient être que des exemples de mise en oeuvre, même si ces exemples seront réutilisables.