Discussion :

[zouip]

Bonsoir,

J'ai récemment téléchargé le soft de Bruno Pages dans le cadre d'un assez gros projet PHP. Je profite de ce post pour féliciter son auteur (qui rode sur ce forum a priori) car il est très complet et très bien pensé.

J'ai cependant quelques petites questions à propos de la génération de code...
J'ai procédé à l'insertion de plusieurs classes liées entre elles par des relations structurelles (généralement des realizations ou des dependencies). J'ai généré un artifact par classe. Lors de la generation proprement dite, tout semble fonctionner correctement. Néanmoins, lorsque j'ai ouvert les fichiers source générés, je n'ai trouvé aucun include/require qui permette de résoudre les dépendances entre mes différentes classes.

Aussi j'aimerais savoir si la génération des include était possible et si oui, comment puis-je procéder. Merci d'avance à ceux qui auront lû ce post

[bruno_pages]

Bonjour,

Php est le seul langage pour lequel il n'y a pas de génération spécifique d'include/require : dans la définition d'un artifact il n'y a pas de macro ${includes} ou autre

pour le moment le seul moyen d'en demander la génération est de les écrire à la main directement dans la définition de l'artifact

questions pour une éventuelle prise en charge par le générateur :

• j'ai l'impression qu'on peut mélanger sans problèmes les formes include et require et donc qu'une seule macro ${includes-requires} suffit (pas besoin d'avoir les deux macros spécifiques ${includes} et ${requires}), vrai ?
• à priori la forme include/require doit aussi pouvoir spécifier le chemin d'accès, je ne sais pas s'il y a des règles en vigueur concernant Php, est-ce que pouvoir choisir comme pour C++ entre without path,with absolute path et with relative path convient ?
• par contre je ne sais pas s'il y a l'équivalent de l'option -I des compilateurs C++, et donc s'il est nécessaire d'avoir aussi with root relative path

P.S. je rode aussi dans le sous forum dédié à Bouml

[zouip]

Il n'y a en effet pas de réelle différence entre require et include si ce n'est le niveau d'erreur qu'il provoque. Si un include échoue, il produira un warning mais le programme poursuivra son execution tandis que lorsqu'un require échoue, il stoppe l'execution du script par un fatal error.

Au niveau du chemin d'accès, il n'y a pas de grande différence avec ce qui se passe en C++. On peut spécifier un chemin relatif ou absolu (la syntaxe <> n'est pas présente et n'a pas lieu d'être). Le fait de spécifier des chemins relatifs posent cependant quelques problèmes étant donné que ces chemins sont relatifs au fichier du script executé et non au fichier du script qui fait l'inclusion. Les développeurs qui souhaitent travailler avec des chemins relatifs utilisent donc généralement la solution suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

require_once dirname(__FILE__) . "/relative_path/script.php";

PS: je n'avais pas vu le forum bouml

[bruno_pages]

ok, déjà il y a donc 4 formes : include include_once require et require_once (légales ou non suivant la version de Php), il faudra donc 4 stéréotypes pour permettre à l'utilisateur de choisir

Le fait de spécifier des chemins relatifs posent cependant quelques problèmes étant donné que ces chemins sont relatifs au fichier du script executé et non au fichier du script qui fait l'inclusion.

cela veut dire que :

• en mode relatif il faut toujours utiliser dirname, même si le script incluant et le script inclus sont dans le même répertoire, au cas où le script incluant soit lui même inclus par un troisième placé ailleurs.
• le mode "relatif au projet" n'a pas de sens

PS: je n'avais pas vu le forum bouml

et pourtant c'est celui que je référence sur les sites de bouml

[bruno_pages]

le mode "relatif au projet" n'a pas de sens

je viens de voir qu'il est possible de spécifier des répertoire grâce à include_path, le relatif projet semble donc utile

ces chemins sont relatifs au fichier du script executé et non au fichier du script qui fait l'inclusion

les essais que j'ai fait contredise cela :
dans le répertoire courant j'ai le fichier f.php et le sous répertoire sub qui lui même contient les fichiers f1.php et f2.php
f.php require sub/f1.php et sub/f1.php require f2.php

je peux sans problème faire "php f.php" ou "php sub/f1.php" donc en particulier la forme require f2.php ne pose pas de problème alors que le chemin est bien relatif au fichier qui fait l'inclusion, ce qui me parait être la moindre des choses. J'ai aussi fait des essais avec un sous répertoire subsub sous sub.

je ne vois donc pas d'intérêt à utiliser dirname

est-ce lié à l'utilisation de php 5 ?

[bruno_pages]

zouip, sans réponse à mes questions je ne pourrais pas ajouter la production automatique des includes/requires pour Php

[CyberDomovoy]

Du nouveau de ce coté?
Je suis sous debian lenny, et j'ai pas trop la motiv de mettre mon nez dans le code ^^

Bruno, pour infos:

require et require_once -> génère une erreur fatale si le fichier n'est pas trouvé
include et include_once -> génère un warning, mais le script continue

Donc dans la mesure ou les fichiers a inclure sont "a prioris" nécéssaire a la déclarations des classes et/ou à l'exécution du code, il me semble raisonnable d'oublier les include au profit des require.

require_once -> s'assure que le fichier ne serat pas inclut plusieures fois, autrement dit, si le fichier a déjé été inclu, ne fait rien.

Dans la mesure ou les fichiers inclus sont a prioris des déclarations de classe ou de fonctions, il me semble au final raisonnable d'utiliser require_once.

Tout ca pour dire, te galère pas avec les differentes fonctions d'inclusions, je pense qu'utiliser uniquement require_once de la meme facon qu'un #include en c++ est amplement suffisant.

En ce qui concerne la facon dont php trouve les fichiers:
Si le chemin est absolu ou relatif (cad qu'il commence par "/", "./" ou "../"), php cherche le fichier a l'endroit spécifié uniquement, pour les chemins relatif la recherche se fait a partir du script courant.
Si aucun chemin n'est spécifié ("repertoire/fichier.php"), la recherche se fait dans les repertoires de l'include path (equivalent de PATH sous linux).

Autrement, une option pour les includes relatifs au projet signifierait que le répertoire du projet est dans le include_path.
Si les includes ne sont pas relatifs au projet deux options se présentent: relatifs au fichier (tout les includes seront alors précédés de "./") ou absoluts.

plus d'infos: http://www.php.net/manual/fr/function.include.php

[bruno_pages]

Bonjour,

Du nouveau de ce coté?

non, car je n'ai jamais eu de réponse malgré le up d'il y a plus d'un an

Je suis sous debian lenny

Utilisez-vous uniquement le paquetage fait par Debian, ou compilez-vous Bouml, ou utilisez-vous arakhne ?
Je demande cela parce que la dernière version faite par Debian pour lenny est la 4.4.2 du 14 juillet 2008, c.a.d. qu'il n'y aura jamais de mise à jour.

il me semble au final raisonnable d'utiliser require_once.

ok

Si aucun chemin n'est spécifié ("repertoire/fichier.php"), la recherche se fait dans les repertoires de l'include path (equivalent de PATH sous linux).
...
Si les includes ne sont pas relatifs au projet deux options se présentent: relatifs au fichier (tout les includes seront alors précédés de "./") ou absoluts.

je ne comprends pas, il y a un chemin relatif dans "repertoire/fichier.php", et ./ ne semble pas necessaire car dans l'exemple ci dessous require_once 'sub/f2.php'; marche très bien et il est inutile d'utiliser require_once './sub/f.php'; :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
bruno@linux-ysqo:/tmp/php> ls -lR
.:
total 8
-rw-r--r-- 1 bruno users   38 avr 18 10:13 f1.php
drwxr-xr-x 2 bruno users 4096 avr 18 09:45 sub

./sub:
total 4
-rw-r--r-- 1 bruno users 35 avr 18 10:13 f2.php
bruno@linux-ysqo:/tmp/php>
bruno@linux-ysqo:/tmp/php> cat f1.php
<?php

require_once 'sub/f2.php';

?>
bruno@linux-ysqo:/tmp/php>
bruno@linux-ysqo:/tmp/php> cat sub/f2.php
<?php

echo "f2 est trouve\n";

?>
bruno@linux-ysqo:/tmp/php>
bruno@linux-ysqo:/tmp/php> php f1.php
f2 est trouve
bruno@linux-ysqo:/tmp/php>

[CyberDomovoy]

Du point de vue de php "repertoire/fichier.php" est recherché dans le include_path, on a l'"impression" qu'il est traité comme un chemin relatif, car dans la configuration de base de php, "./" est dans le include_path.
Sur ma configuration, j'ai viré "./" du include_path, ton example ne marcherait pas.

Pour répondre a tes questions:
J'utilise le paquetage debian, mais j'ai téléchargé aujourd'hui les sources et commencé a regarder comment etait organisé tout ca.
J'ai vu que tu gère la génération du php dans "PhpGenerator/UmlArtifact.cpp", et plus précisemment dans "UmlArtifact::generate()".

Je pense qu'il serait aussi interessant d'ajouter une fonction pour générer automatiquement les commentaires phpdoc ( http://www.phpdoc.org/ ):
Ceux-ci sont assez proches des commentaires Javadoc, il faudrait renommer celui-ci car je trouve qu'une option se référant a Java n'a pas sa place dans un environnement PHP...
Il serait judicieux d' ajouter un élément ${phpdoc}, qui me semble plus évocateur que ${comment}.

Les commentaires Phpdoc seraient générés en utilisant la description bien sur.

En plus de cela, au niveau des artefacts, il faudrait des paramètres pour renseigner l'auteur, son mail, la license, un lien vers la license et la version.
Les même parametres devraients etres présents pour les classes, par défaut ils seraient hérités de l'artifact.

Phpdoc utilise une description courte (une ligne), et une longue (pouvant faire plusieurs lignes).
Je ne pense pas necessaire de séparer les deux dans bouml, utiliser la description suffit.
Il serait par contre necessaire d'informer l'utilisateur de ce fonctionnement.

Pour les artefacts, le phpdoc généré devrait ressembler a ca:
/**
* ${comment}
*
* @version ${version}
* @author ${author} <${author_mail}>
* @license ${license_url} ${license}
* @package ${package}
*/
En plus de @package, les commentaires phpdoc peuvent aussi contenir un @subpackage.
Par contre, je ne voit pas trop comment appliquer cela a la hierarchie de packages de bouml.

Pour les classes:
/**
* ${comment}
*
* @author ${author} <${author_mail}>
* @package ${package}
*/

Pour les attributs:
/**
* @var ${type} ${name} ${comment}
*/
Note: ici le commentaire doit etre court

Pour les methodes:
/**
* ${comment}
*
* @param ${t0} ${p0} ${comment_for_param0}
* @param ${t1} ${p1} ${comment_for_param1}
* @return ${type} ${comment_for_type}
*/
Note: La y'a un probleme pour les commentaires des parametres et de la valeur de retour... Il faudrait soit les oublier, soit faire en sorte que l'utilisateur puisse les mettre (compliqué... non?), soit utiliser le contenu des contraintes (je sais pas comment ca marche ca...)

Tout ca permet de générer les commentaires phpdoc de base, bien sur il est possible de faire bien plus avec phpdoc, mais bouml n'a pas a aller aussi loin.

Cela implique d'ajouter la gestion des types de variables dans php.
Meme si php est un langage non typé, il permet de contraindre les arguments des methodes a certains types (cf http://www.php.net/manua/fr/language...ypehinting.php )
De plus cela est necessaire pour pouvoir générer des commentaires Phpdoc renseignant sur les types des attributs/methodes/parametres.

Je peux bosser avec toi la dessus si tu veux, ca m'intéresse.
Du genre on se capte sur un canal irc, si tu m'explique le fonctionnement de ton code, ca m'evitera de passer des jours a comprendre, et a nous deux je pense qu'on pourrait implémenter tout ca assez vite.

[CyberDomovoy]

Ha, et...
Pas de "vous" avec moi stp ^^

[bruno_pages]

Bonsoir,

on a l'"impression" qu'il est traité comme un chemin relatif, car dans la configuration de base de php, "./" est dans le include_path.

ok, donc le plus sure est de forcer la présence de ./ en tête de chemin relatif vers un sous répertoire

il faudrait renommer celui-ci car je trouve qu'une option se référant a Java n'a pas sa place dans un environnement PHP...

j'ai également mis javadoc style pour C++, et je ne le changerai pas car cette option ne produit pas de commentaire phpdoc, juste /** */

il faudrait des paramètres pour renseigner l'auteur, son mail, la license, un lien vers la license et la version...

il manque l'age du capitaine ...

Plus sérieusement, je ne vais certainement pas forcer cela, de plus il est totalement inutile de modifier Bouml afin d'obtenir ce résultât car

• les formes @{xxx} vous permettent de définir vos propre macros
• les options de génération vous permettent de définir des descriptions par défaut par type d'élément, ces définitions étant utilisées via le bouton default dans les boites de dialogue.

avant de demander la modification de Bouml il pourrait être utile de lire sa doc

@package

pour le moment je ne gère pas les paquetage dans Php

Note: La y'a un probleme pour les commentaires des parametres

s'il est possible d'établir une description par défaut des opérations celle-ci ne peut évidemment pas prendre en compte les paramètres dont le nombre est inconnu. Le plus simple est d'écrire un plug-out modifiant les description des opérations pour ajouter/retirer des paramètres. A partir du moment ou il est plus simple de retirer des paramètres que de les ajouter il est également possible d'avoir une définition par défaut supposant par exemple qu'il y a 3 paramètres

Cela implique d'ajouter la gestion des types.

cette gestion existe depuis la version 4.9.3 distribuée en janvier 2009, et c'est bien-sûr documenté

[CyberDomovoy]

ok, donc le plus sure est de forcer la présence de ./ en tête de chemin relatif vers un sous répertoire

C'est tout a fait cela.

j'ai également mis javadoc style pour C++, et je ne le changerai pas car cette option ne produit pas de commentaire phpdoc, juste /** */

Je m'incline je comprend tout a fait ce point de vue.
Je suis en train de modifier les sources pour inclure une macro ${phpdoc}, totalement indépendante de ${comment}.
Maintenant je peu comprendre que ce ne soit pas quelquechose que tu souhaite inclure a bouml... Dans ce cas tant pis, je l'aurais au moin pour moi

il manque l'age du capitaine ...

Oui je sais, j'ai tendance a m'emporter ^^

Plus sérieusement, je ne vais certainement pas forcer cela, de plus il est totalement inutile de modifier Bouml afin d'obtenir ce résultât car

• les formes @{xxx} vous permettent de définir vos propre macros
• les options de génération vous permettent de définir des descriptions par défaut par type d'élément, ces définitions étant utilisées via le bouton default dans les boites de dialogue.

avant de demander la modification de Bouml il pourrait être utile de lire sa doc

Je suis au fait de ce fonctionnement, mais il me semble que ces paramètres seraient utiles pour tout les languages, pas seulement php.
En effet la gestion des version/auteur/license devrait (a mon avis), faire partie de tout environnement de developpement (particulierement la license...); mais ce n'est que mon humble avis.

pour le moment je ne gère pas les paquetage dans Php

Il se trouve que php lui meme ne gere pas les packages... sauf depuis les dernieres versions ou la notion de namespaces a été introduite, c'est pourquoi je disais que je ne voyait pas comment appliquer la hierarchie de packages a php...

s'il est possible d'établir une description par défaut des opérations celle-ci ne peut évidemment pas prendre en compte les paramètres dont le nombre est inconnu. Le plus simple est d'écrire un plug-out modifiant les description des opérations pour ajouter/retirer des paramètres. A partir du moment ou il est plus simple de retirer des paramètres que de les ajouter il est également possible d'avoir une définition par défaut supposant par exemple qu'il y a 3 paramètres

J'ai essayé de comprendre comment, dans PhpGenerator, tu gérait la génération des parametres des methodes (${(} et ${)} impliquant ${t0}, ${p0}, ${t1}, ${p1} et ainsi de suite), mais sans succes. J'ai du louper quelque chose... Si tu pouvais m'éclairer la dessus? Je ne parle pas ici d'ajouter/retirer des parametres, mais simplement d'utiliser ceux déclarés en uml pour générer le phpdoc correspondant (@param ${tx} ${px}).
Etant donné qu'il n'y a pas de commentaire pour les parametres, l'utilisateur devrais lui-meme ajouter une courte description s'il le désire, mais au moin, ${phpdoc} génererais la doc minimale.

cette gestion existe depuis la version 4.9.3 distribuée en janvier 2009, et c'est bien-sûr documenté

Hmmm... il faut que je regarde ca, je n'avais pour l'instant utilisé que la version de debian lenny (4.4.2-1), mais je travaille maintenant sur la 4.20, alors y faut que je me mette a jour

Quoi qu'il en soit, je suis pour l'instant en train d'essayer d'ajouter la gestion de phpdoc (minimale) et des dépendances a bouml.
Mon travail sera exposé sur ce forum (peut-etre faudrait-il que je crée un autre post pour cela?)
Merci de tes réponses.

[bruno_pages]

Je suis au fait de ce fonctionnement, mais il me semble que ces paramètres seraient utiles pour tout les languages, pas seulement php.
En effet la gestion des version/auteur/license devrait (a mon avis), faire partie de tout environnement de developpement (particulierement la license...);

encore une fois il suffit de le mettre dans la définition par défaut des artifact, et si besoin sauver le tout dans un projet template pour retrouver tout cela lors de la création des nouveaux projets

Etant donné qu'il n'y a pas de commentaire pour les parametres, l'utilisateur devrais lui-meme ajouter une courte description s'il le désire, mais au moin, ${phpdoc} génererais la doc minimale.

d'où le fait que la seule solution viable est qu'ils soient présents dans la description pour que l'utilisateur puisse ajouter un commentaire associé, et non de modifier le générateur pour qu'il essaye de les mettre. Il n'y a en effet strictement aucune plus value à remettre dans le commentaire phpdoc ce qui existe au niveau du profil d'une opération

[CyberDomovoy]

encore une fois il suffit de le mettre dans la définition par défaut des artifact, et si besoin sauver le tout dans un projet template pour retrouver tout cela lors de la création des nouveaux projets

Le but du jeu n'est-il pas de simplifier la vie des utilisateurs?

Il n'y a en effet strictement aucune plus value à remettre dans le commentaire phpdoc ce qui existe au niveau du profil d'une opération

A part peut-etre générer un documentation complète... non?

Enfin bref, je peu comprendre que tu n'ai pas envie d'intégrer tout cela a bouml et tu en as le droit.
Ceci dit ce sont des fonctionnalités qui m'importent, et fort heureusement ton code est en GPL, je vais donc essayer de satisfaire mes souhaits.
Vive le libre \o/

[bruno_pages]

Le but du jeu n'est-il pas de simplifier la vie des utilisateurs?

oui, c'est pour cela que j'offre le moyen de modifier les définitions par défaut

mais peut être qu'il y a un quiproquo ?

II est bien évident que par exemple l'en-tête d'un fichier est propre à chacun ou à chaque société, cela veut dire que je ne peux pas l'imposer. Il suffit donc d'entrer celle-ci une fois dans la définition par défaut d'un artifact au niveau des options de compilation, et elle sera réutilisée par défaut lors de la création des futurs artifacts. Si cela ne simplifie pas la vie des utilisateurs il faut m'expliquer ...

A part peut-etre générer un documentation complète... non?

faut-il comprendre pas là que phpdoc ne regarde que les commentaires, et ne regarde pas le profile des opérations ?

[CyberDomovoy]

Il suffit donc d'entrer celle-ci une fois dans la définition par défaut d'un artifact au niveau des options de compilation, et elle sera réutilisée par défaut lors de la création des futurs artifacts.

Si je comprend bien, tu me dis qu'il faut par exemple que j'ouvre les options de générations du projet, que j'edite (pour php) "file default content" et que tout les artifacts php heriteront de cette definition par defaut?
Si j'ai tout bon, je ne conteste pas ca, c'est en effet la facon dont fonctionne la chose.
Mais si mon projet utilise du php ET du c++ par example, alors il faut que je renouvelle l'opération pour chaque language?
Ne serait-il pas plus simple et plus clair de rajouter quelques simples macro a bouml, utilisables par tout les languages? Du genre ${author}, ${version}...
De plus ca apporterait un peu plus de flexibilité a l'utilisateur quand il définit ses options de génération justement.
Mais peut-etre qu'il ya quiproco en effet... Je suis pas sur qu'on parle de la même chose ^^
Ou du moin pas appliquée de la meme facon.

faut-il comprendre pas là que phpdoc ne regarde que les commentaires, et ne regarde pas le profile des opérations ?

Phpdoc regarde les définitions en effet, mais quand tu lis leur doc, ils t'informent aussi qu'il est préférable d'utiliser les "macros" de leurs commentaires, le résultat de la doc pouvant grandement changer selon le "template" que tu utilise pour générer ta doc.
Certains afficheront certaines infos, d'autres non, ou d'une autre maniere, ou... que sais-je encore.
Je pense que d'un point de vue général il est préférable de ne pas s'appuyer sur des comportements "par defaut" d'une quelconque application, mais bel et bien de suivre ses recommendations.

[bruno_pages]

il faut par exemple que j'ouvre les options de générations du projet, que j'edite (pour php) "file default content" et que tout les artifacts php heriteront de cette definition par defaut?

oui

pourquoi ne pas lire la doc et/ou regarder par exemple cpp_exemple.wmv ?

Ne serait-il pas plus simple et plus clair de rajouter quelques simples macro a bouml, utilisables par tout les languages? Du genre ${author}, ${version}...

rappel :

• les formes @{xxx} vous permettent de définir vos propre macros

[bruno_pages]

Bonjour,

le générateur Php produit désormais les formes require_once, la production des chemins est paramétrable (j'ai mis le mode relatif même s'il n'est pas compatible avec tout les cas potentiels possibles)

beaucoup d'autres nouveautés dans la version 4.21, voir historique pour plus d'informations

Bonnes modélisations