Journal Mise à disposition de mes outils pour générer du code PHP

Posté par David Sporn (site web personnel) le 20 décembre 2006 à 23:05.

Étiquettes : aucune

déc.

2006

Cher journal,

Tout d'abord, cela fait un moment que je travaille sur les outils dont je vais parler et que les packages sont disponibles sur ma page sourceforge [1] ("release early, release often" qu'ils disent), mais je n'en parle maintenant pour une raison simple : c'est maintenant suffisamment prêt.

De quoi s'agit-il ? Mon but est de générer du code à partir de fichiers de description en XML selon un schéma ad-hoc, le-dit code étant pénible à écrire et à maintenir (par exemple l'écriture du triptyque champ privé-accesseur en lecture-accesseur en écriture)
Pas la peine de crier au génie, peut-être même que ça existe déjà, sauf qu'il s'agit ici de généraliser du code PHP que j'ai écris moi-même.

Les outils disponibles sont les suivants :
- src-bean : génère un équivalent des JavaBean, mais avec un petit plus : deux méthodes pour copier les attributs vers ou depuis un objet quelconque possédant les même attributs (et donc les même nom d'accesseurs)

- src-request : génère un "bean" avec des attributs en lecture seule (i.e. que des getXXX) pour récupérer les valeurs présente dans $_REQUEST, l'intérêt de la chose étant de : faire quelques manipulations pour contraindre la valeur récupéré, comme la conversion en nombre entier, en un texte d'une seule ligne, ou encore fournir une valeur par défaut si il n'y a pas de valeur ; supporter des "espaces de nom", en fait un préfixage des noms de valeurs. Voir [2] et [3]

- src-form : génère du code PHP générant le corps d'un formulaire, l'intérêt de l'outil étant : le code généré n'a pas de mise en page par tableau, tout se fait par CSS, de nombreuse classes CSS étant générée pour pouvoir cibler un champ précis si nécessaire ; les tags labels avec les attributs "for" adequats ce qui permet d'exploiter ce tag correctement ; la possibilité de préfixer les nom des champs ("espace de nom") permettant des inclusions multiple ; la possibiliter de spécifier une expression php pour l'objet contenant les données du formulaire et la fonction permettant d'afficher les label traduits.

- src-linker : génère le code d'une classe permettant de générer les leins html d'un site avec quelques paramètres. Voir [4]

- src-database-table : génère une API de bas niveau pour manipuler une table de base de données. L'intérêt de l'outils est que le nom des colonnes et de la table n'est pas totalement figé avec le support encore une fois d' "espace de noms". Voir [5]

- src-struts : génère des scripts php dont le cheminement reprend celui de struts, avec la reprise des bean pour les données de formulaire, les classes actions, le concept du forward-mapping.

Une application de démonstration [6] et [7] montre la mise en oeuvre de certains modules (src-bean, src-request, src-form et src-struts).

De manière générale, j'utilise des scripts ant pour automatiser la génération de code (transformation des fichiers XML avec des script XSLT), j'ai organisé les fichiers pour prévoir le support de différents langages de programmation.
Certains outils peuvent générer un fichier de description pour un autre outil, ce qui permet de les enchaîner :
Ainsi, src-database-table peut générer des descriptions de formulaires (pour la saisie des données et des critère de recherche), src-form peut générer des description pour src-request (pour récupérer les valeurs des différents champs) et src-request peut générer des descriptions de bean (pour stocker toutes les valeurs dans un bean et ne plus faire de tests et autres).

Un précision importante : seuls les modules utilisés dans la démonstration ont été correctement testé, pour les autres modules, je les ai utilisé une fois et ça marche -j'utilise le code généré sur un de mes site-, mais il faut s'attendre à de mauvaises surprise. D'autre part, la tâche ant "style" ne fonctionne pas avec gcj, il faut un jdk/jre de Sun.

Pour conclure, pourquoi j'ai fait ça ? Pour répondre à mes besoins, pour travailler mes compétences PHP et concrétiser certaines de mes réflexions.
Pourquoi j'en parle ? Parce que ça peut intéresser certains d'entre vous, c'est sous licence libre (GPL), et ça flatte mon ego (trèèèès important ça).

Une dernière chose en passant : malgrè une relecture assez attentive, j'ai pu laissé des fautes, je vous demande pardon à l'avance.

[1] http://sourceforge.net/projects/websitesystem/
[2] http://www.sporniket.com/page/blog/php/200502091420
[3] http://www.sporniket.com/page/blog/php/200502091442
[4] http://www.sporniket.com/page/blog/php/200502171119
[5] http://www.sporniket.com/page/blog/php/200502091730
[6] http://www.sporniket.com/htmltools/textconverter.php
[7] http://www.sporniket.com/htmltools/linkgenerator.php

# re

Posté par Sylvain (site web personnel) le 20 décembre 2006 à 23:27. Évalué à 2.

c'est quoi un bean ?
- [^] # Re: re
  
  Posté par David Sporn (site web personnel) le 20 décembre 2006 à 23:36. Évalué à 3.
  
  Ah, c'est un terme utilisé chez le programmeurs Java pour désigner une classe servant de stockage à des attributs, chaque attribut étant accessible avec une méthode getXxx/setXxx (selon les besoin, seul getXxx ou setXxx peut être disponible).
  
  Il doit y avoir un terme plus générale à la programmation objet, mais jen e le connaît pas...
  - [^] # Bean
    
    Posté par meh (site web personnel) le 21 décembre 2006 à 06:52. Évalué à 1.
    
    Est-ce une sorte de classe abstraite ?
    - [^] # Re: Bean
      
      Posté par David Sporn (site web personnel) le 21 décembre 2006 à 07:26. Évalué à 1.
      
      Non, en général. Un exemple (en PHP4) :
      
      class SampleBean
      {
      //==========
      //Accessors
      /* ----=HTML code=---- */
      
      /**Reads HtmlCode.
      */
      function getHtmlCode()
      {
      return $this->myHtmlCode ;
      }
      
      /**Changes HtmlCode.
      */
      function setHtmlCode($aHtmlCode)
      {
      $this->myHtmlCode = $aHtmlCode ;
      }
      
      //==========
      //Fields
      /**HTML code.*/
      var $myHtmlCode ;
      
      }
      
      Il s'agit donc d'une convention d'écriture, formalisé et désigné sous le terme "bean" en Java. L'idée était d'utiliser les fonctions d'introspection (examen d'une classe -champs, méthodes-) pour en déduire la liste des attributs, et d'utiliser une interface graphique pour concevoir des application de manière visuelle, à l'image de Visual Basic (les widgets en Java utilisent ce formalisme).
# Ou alors on peut utiliser symfony ...

Posté par goofy le 20 décembre 2006 à 23:50. Évalué à 4.

Ca fait déjà tout ;) ...
S'en parler des plugins ...
Du générateur d'administration ...
Bref le "ROR" du php5 ...
Ah oui et même le xml c'est trop ch.. à écrire heureusement il y a le yaml

http://www.yaml.org
http://www.symfony-project.com

Et en plus c'est français, je crois, pour ceux qui pratiquent le patriotisme économique ...
- [^] # Re: Ou alors on peut utiliser symfony ...
  
  Posté par David Sporn (site web personnel) le 21 décembre 2006 à 00:55. Évalué à 4.
  
  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 Damien Metzler le 21 décembre 2006 à 11:07. Évalué à 2.
    
    J'ai aussi testé symfony et c'est impressionnant.
    
    On entre dans un monde réel objet en PHP et ça c'est super. Je ne détaillerai pas toutes les avancées mais ça permet plein de choses (interfaces, variables statiques etc...)
    
    Symfony est en fait un framework regroupant plusieurs librairies déjà existantes, mais de manière intégrée :
    - Propel/Creole pour l'object-relationnal mapper
    - Mojavi pour la partie MVC
    - Scriptaculous pour tout l'AJAX
    
    Un premier écran d'application se configure en deux commandes et chaque nouveau module en une seule commande.
    
    Pour répondre à tes différents points :
    
    - Pour les critères, Propel/Creole utilise un object Criteria auquel tu ajoutes tout ce que tu veux (jointure sur autres table, tri etc...). Je pense que tu trouveras tout ce que tu veux là comme critères avec ça. En fait on passe l'objet Criteria à la requête doSelect de l'OMPeer et on récupère un tableau d'objets (comme des Beans).
    
    - YAML ne nécessite quasiment pas d'apprentissage, c'est comme du XML en beaucoup moins verbeux (peut être moins puissant aussi, mais pour de la conf ça suffit amplement)
    
    - Quand on utilise $this->getRequest()->getParameter('id'), cela récupère le paramètre id de l'application. Dans la plupart des cas cela correspond à la valeur passée dans l'url mais pas forcément : un fichier de conf permet de mapper les smart_url sur des noms de variables. De plus le fait d'utiliser les balises link_to dans les templates transforme automatiquement les url pour que tout fonctionne bien.
    
    - concernant les détails des url, le fichier routing.yml permet justement de faire tout ce que tu veux au niveau du routage de ton front controller. Il est vrai que cela impose mod_rewrite du coup, mais il me semble que c'est configurable. L'avantage c'est que c'est traité à un haut niveau dans le framework et que du coup c'est modifiable...
    
    Après, il est vrai qu'on est bien avec ses outils, j'ai aussi fais les miens... J'ai testé symfony il y a une semaine (c'est pour dire que c'est frais) et j'ai été vraiment impressionné. Il y a peu ou pas de choses que l'on ne peut pas faire ou de situation où l'on soit bloquée. Il y a toujours un comportement par défaut que tu peux customiser à ta manière.
    
    De plus la documentation est d'un qualité et d'une intelligence rare. Leur "calendrier de l'avent" est un exemple pas à pas qui permet d'apréhender le framework à son rythme (théoriquement 24 jours) et présente bien tous les avantages de la méthode.
    
    La documentation sur le site en lui même est basée sur des Use-Cases très pertinents indexés par plusieurs mots-clés et si on veut plus de doc, on va voir sur les sites des librairies pour en avoir de meilleures (ya juste que phpdb.org était down ces derniers temps...)
    
    Le résultat est que du coup, je ne me charge que très peu des détails techniques de l'application et je me focalise sur les aspets métier et ergonomie. Les applications résultantes sont du coup de bien meilleure qualité. Code Less, Code better... J'ai peut être passé autant de temps à développer l'appli, mais je l'ai passé sur les aspets important et moins sur les détails techniques.
    
    Dommage que beaucoup de mes serveurs soient encore en php4 sinon je crois que je ferais migrer beaucoup d'appli sur ce framework.
- [^] # Re: Ou alors on peut utiliser symfony ...
  
  Posté par Laurent J (site web personnel, Mastodon) le 21 décembre 2006 à 11:49. Évalué à 3.
  
  ou y a aussi jelix, http://jelix.org, qui va bientôt sortir en beta1... (trés stable contrairement à ce que dit son nom, puisque utilisé par exemple sur un site à trés forte audience...).
  
  /me devrait faire un journal un de ces quatres...
- [^] # Re: Ou alors on peut utiliser symfony ...
  
  Posté par Brice Carpentier le 21 décembre 2006 à 12:55. Évalué à 2.
  
  développé à Asnières par une boite qui s'appelle sensio [1] plus précisemment.
  
  [1] http://www.sensio.com
# Mmmmm...

Posté par ナイコ (site web personnel) le 21 décembre 2006 à 00:49. Évalué à 9.

Humour récursif :
...j'ai pu laissé des fautes,...
- [^] # Re: Mmmmm...
  
  Posté par David Sporn (site web personnel) le 21 décembre 2006 à 00:56. Évalué à 4.
  
  tu as oublié le "malgrè" au lieu de "malgré" dans "malgré une relecture assez attentive"...
# Génération PHP avec Acceleo ?

Posté par Etienne Juliot (site web personnel) le 21 décembre 2006 à 09:37. Évalué à 2.

Salut,

sympa ton système, c'est pas mal du tout.
Si je peux te donner un chtit conseil, tu peux jeter un coup d'oeil à Acceleo. C'est un atelier de génération de code qui est quand même très largement plus puissant et plus conviviale que XSLT + XSD.
C'est justement conçu pour être très configurable pour pouvoir générer le code comme bon te semble.

C'est bien sûr OpenSource, dispo sur http://www.acceleo.org, ca s'insère nickel dans le futur environnement de référence pour le développement PHP (fait par Zend et dispo içi : http://www.eclipse.org/php/), des scripts XSLT se migre facilement vers Acceleo, et il commence à y avoir de plus en plus de générateurs basés sur Acceleo, comme moteur de génération.
Prend 5 min pour y jeter un oeil, ça peut valoir le coup.
- [^] # Re: Génération PHP avec Acceleo ?
  
  Posté par David Sporn (site web personnel) le 21 décembre 2006 à 10:08. Évalué à 1.
  
  Oui en effet ça a l'air pas mal ce truc. Je le note dans un coin de ma tête, merci beaucoup.
  
  Et au fait, je n'utilise pas de XSD (pour le moment), et mon choix de xml/xslt a été motivé par deux raisons principales :
  - une bonne expérience de xslt, donc je peux développer rapidement dessus avec le résultat que je veux
  - l'existence de la tâche "style" dans ant, ce qui me permet de limiter mes dépendances à java + ant. Cependant cette dépendance n'est pas très forte, il suffit d'avoir un outil capable d'utiliser xml/xslt et un outils pour automatiser (un simple script shell, make, msdos,...) . J'ai choisi ant+java pour la portabilité. Enfin, je n'impose pas d'IDE pour travailler.
  
  PS: n'oublie pas de rajouter un espace après une url, sinon templeet se trompe dans la génération automatique du lien...
  
  [1] http://www.acceleo.org
  [2] http://www.eclipse.org/php/
# ou alors on peut utiliser CakePHP ...

Posté par Brice Carpentier le 21 décembre 2006 à 13:01. Évalué à 2.

Ca fait déjà tout ;) ... [1]
Sans parler des plugins ...
Du générateur d'administration ...
Bref le "ROR" du php4 ou 5 ...
Ah oui et comme c'est trop ch.. de devoir décrire sa structure de base, elle peut être devinée à partir de l'objet php. [2]

Et en plus c'est OpenSource, bien entendu, pour ceux qui pratiquent le librisme économique ...

[1] http://www.cakephp.org
[2] http://manual.cakephp.org/chapter/models
- [^] # Re: ou alors on peut utiliser CakePHP ...
  
  Posté par goofy le 21 décembre 2006 à 15:47. Évalué à 2.
  
  Oulah je sais pas si tu va pas recevoir une lettre recommandé de mon service juridique pour plagiat/troll toi ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.