double fonctions d'include

Sergnal · 12-05-2010 14:00:12

Bonjour,

J'ai une problématiques assez simple à résoudre mais soit ce n'est pas optimisés, soit je ne sait pas faire.

Le but est de "trier" les scripts php d'un site web (plusieurs centaines de pages tout de même, mais on va se concentrer sur les interfaces) de manière à en faciliter la maintenance (parce que les précédents développeurs ont rajoutés/modifiés au fur et à mesure et donc le résultat...).

Techniquement ça se traduit par la décomposition de chaque fichier en trois script : fichier_data.php (celui qui contient les requêtes sql et les transformations de données), fichier_echo.php (celui qui contient tout l'affichage) et fichier_main.php (celui qui rassemble les deux autres).

Donc en théorie un fichier_main.php contiendrait :

include('fichier_data.php');

include('fichier_echo.php');

Ca marche c'est tout beau. Mais, contrainte : pour des raisons une nouvelle fois d'entretien il faudrait pouvoir, à chaque include, aller écrire dans la bdd le fichier appelant et le fichier appelé pour générer automatiquement l'arborescence du site. Bien entendu l'écriture dans la base ne dois pas s'effectuer à chaque fois mais par exemple lorsqu'on passe dans un mode spécifique (une variable de session).

D'où première solution trouvée : une fonction intermédiaire "mon_include" (incomplète au niveau du sql certes mais ce n'est pas le sujet ici).

$ordre_appel=0;

function mon_include($page_mere,$page_fille)

{

global $ordre_appel;

$ordre_appel+=1;

$sql="INSERT into plan_scripts('".$page_mere."','".$page_fille."','".$ordre_appel."','inclusion')";

include($page_fille);

}

Ce qui nous donnerait donc un fichier_main contenant (en plus d'un lien vers la fonction ci-dessus :

mon_include('fichier_main.php','fichier_data.php');

mon_include('fichier_main.php','fichier_echo.php');

Problème majeur : la portée des variables. En effet l'affichage marche sans problème mais ne peut pas récupérer les variables que devrait lui passer fichier_data.php puisque celui-ci est appelé dans une fonction et donc ses variables sont considérées comme locale à cette fonction.

Il y a encore la solution de laisser les includes et de créer une fonction post_include qui se chargerait uniquement d'écrire dans la base ou de tricher en utilisant eval(), mais ça ne me satisfait pas.

C'est pour cela que je sollicite humblement votre avis pour savoir :

1/ si notre stratégie vous parait pertinente.

2/ si mon problème a une meilleure solution que celles que j'évoque.

3/ si on peut modifier/copier les fonctions natives de php (ou où trouver de la documentation là-dessus, je n'ai rien trouvé et je ne sais pas comment elles sont faites donc je ne sais pas si c'est possible).

Merci d'avoir lu jusqu'au bout. J'espère avoir réussit à exposer mon problème assez clairement.

Jc · 12-05-2010 23:49:59

Bonsoir,

Alors je vais essayer de répondre à toutes tes questions et désolé si je le fais un peu dans le désordre.

Je vais avant cela si tu me le permets faire une petite introduction à ma réponse^^. Ton problème est le problème majeur du developpeur sur les technologies web: Choisir entre remettre en ligne un code existant sur un nouveau cahier des charges et redevelopper un nouveau "noyau". La contrainte pour le choix se résume à optimiser le temps/coût/moyens pour qu'ils soient minimes.
Bien que redevelopper le code sur les technos web soit plus du 3/4 du temps à la fois le plus rapide et le moins coûteux - pour peu que le code existant soit pas /peu documenté et couteux à maintenir - la décision passe avant tout par une analyse globale au niveau ingénierie sur le code éxistant et en fonction d'un nouveau cahier des charges précis pour :
- Etre en mesure d'évaluer ce que doit être un code final optimisé en fonction de l'existant et de ce qu'on veut obtenir
- Une évaluation précide du temps et des moyens à mettre en oeuvre pour l'atteindre dans une contrainte de temps définie dans le cahier des charges.

En conséquence, il est évident qu'il est impossible à partir de là au vu des informations que tu nous donnes sur ton projet, de répondre (du moins en ce qui me concerne) aux questions suivantes d'une manière avisée :

sergnal a écrit :

1/ si notre stratégie vous parait pertinente.
2/ si mon problème a une meilleure solution que celles que j'évoque.

D'ailleurs quand tu dis

sergnal a écrit :

...de manière à en faciliter la maintenance (parce que les précédents développeurs ont rajoutés/modifiés au fur et à mesure et donc le résultat...).

la question que je te poserais est la suivante : l'objectif est-il de refaire un code "propre" sur l'existant en fonction d'un nouveau cahier des charges, ou s'agit il ici que d'une modification supplémentaire faite au fur et à mesure? Je te laisse réfléchir à la question.

Ensuite, pardonne moi par avance si je vais être un peu cru avec toi, et pardonne moi aussi de ce que je vais te dire, mais par rapport aux maigres informations que tu mets à notre disposition quand tu dis

sergnal a écrit :

Problème majeur : la portée des variables. En effet l'affichage marche sans problème mais ne peut pas récupérer les variables que devrait lui passer fichier_data.php puisque celui-ci est appelé dans une fonction et donc ses variables sont considérées comme locale à cette fonction.

.. il me paraît abérrant que quelqu'un à qui on confie la charge d'un tel projet ne sache pas qu'on peut passer une variable par référence à une fonction en PHP. Et si passer une une variable par référence à une fonction ne peut résoudre ton problème ici, cela prouverait au moins qu'on a aucun élément pour pouvoir te répondre de manière sérieuse et avisée.

D'autre part, je doute fortement qu'un site qui apparemment possède une bibliothèque de plus de 100 fichiers pour le faire tourner, ait une structure où une page x possède une seule et unique page parent. En général, et je suis gentil, un site est redondant de base sur ses liens quand il est développé en statique, et par conséquent on ne parle même pas d'un site dynamique voire basé sur une technologie ajax...
Donc j'ai peut être parlé un peu trop vite, car il est déjà sûr et certain que la structure bdd que tu évoques ne corresponds pas du tout à la structure d'un site web. Tu devrais jeter un oeil sur les structures bdd des logiciels de généalogie ca t'aiderait beaucoup, je sais de quoi je parle étant moi même l'auteur d'un tel logiciel.

Toutefois pour revenir à l'essentiel, je suis quelqu'un assez soucieux à trouver des solutions aux problèmes difficiles à résoudre et qui aime le faire. D'ailleurs à ce sujet, je reste à ta disposition si tu a besoin.

Cordialement,

Jc

Dernière modification par Jc (13-05-2010 11:07:57)

Sergnal · 17-05-2010 11:07:25

Bonjour,

Merci pour cette réponse pour le moins structurée, la preuve est faite, je ne suis pas doué pour expliquer mes problèmes ^^

Mais c'est en forgeant... donc me revoilà tout gonflé d'énergie pour un nouvel essai.

Tout d'abord non je ne connaissait pas le passage de variable par référence (qu'on lui coupe la tête !) mais il ne résoud pas mon problème (ou alors je ne l'ai pas utilisé correctement).

Pour clarifier la situation l'objectif est la réécriture du code à l'occasion de la migration du site vers un autre SGBD, et en profiter pour rendre l'interface plus ergonomique et le code plus clair en fonction d'un nouveau cahier des charges.

Dans mon post précédent j'ai effectivement fait une erreur (que je vais mettre sur le compte de la fatigue) en disant vouloir séparer chaque fichier en trois, il s'agissait en fait de chaque interface (constituée effectivement de plusieursss fichiersss). C'est en testant cette séparation sur une sous-partie du code que je suis tombé sur l'os.
En effet un autre point du cahier des charges demande la création d'une fonction qui prendra en charge tous les appels de fichiers, c'est ce point qui est problèmatique.

De manière "simple" et purement technique :

//fichier_data.php
<?php
$var="val";
?>

//fichier_echo.php

<?php

echo $var;

?>

//fonction.php

<?php

function mon_include($page_mere,$page_fille) //très très simplifiée hein ^^

{

//... traitement ...

include($page_fille);

}?>

//fichier_main.php

<?php

//1 :ça ne marche pas, $var est défini dans la première fonction mon_include et n'est pas accessible ailleurs

include(fonction.php);

mon_include('fichier_main.php','fichier_data.php');

mon_include('fichier_main.php','fichier_echo.php');

//2 :ça marche mais il va falloir ajouter le traitement d'une manière ou d'une autre

//include('fichier_data.php');

//include('fichier_echo.php');

?>

Je cherche donc un moyen de faire marcher la solution 1 (qui puisse marcher avec un fichier contenant n'importe quel nombre de variable) et s'il n'y en a pas je me rabattrai sur la solution 2 (avec les solutions déjà évoquée plus haut si je n'en trouve pas de meilleure).

Voilà j'ai essayé d'être plus clair concernant l'énoncé du problème.

Sinon tu parles des structures bdd des logiciels de généalogie, mais dans quelle optique dois-je y jeter un oeil ?

Encore merci d'avoir pris le temps de me répondre.

Alnoss · 17-05-2010 13:09:20

j'interviens à la volée, mais une petite question se pose

Sergnal a écrit :

<?php
//fichier_data.php
$var="val";
//fichier_echo.php
echo $var;
?>

Comment se fait le transfert de $var d'une page à l'autre ??

Sergnal · 17-05-2010 14:30:52

Justement là est la question, là est le problème ^^

Normalement avec le double include() de la page fichier_main.php le transfert se fait sans problème.

Actuellement avec la double fonction mon_include() il ne se fait pas, ce qui est le comportement logique et normal (les variables restent dans leurs fonctions), mais pas le comportement voulu.

Alnoss · 17-05-2010 15:15:10

en dehors des sessions, je n'envisagerais pas d'autre méthode pour ce cas ... (mais ca n'engage que moi )

mcAllan · 17-05-2010 15:28:47

Hello,

Une inclusion de page à l'intérieur d'une fonction, ça m'interpelle quelque part...
Mais bon, ce n'est que mon avis...

Jc · 18-05-2010 06:49:32

Bonjour,

Tout d'abord, je tenais à te remercier pour ta persévérence et à te dire que ton 2e post est moins clair que le premier pris individuellement. Quand on lit les deux ensemble, je pense commencer à y voir plus clair^^.

Alors je ne sais toujours pas si j'ai bien compris ton problème, donc je m'en excuse, et surement que tu sais déjà tout ce que je vais te dire maintenant, mais peut être que ca t'aidera a y voir plus clair.

PHP est avant tout un language orienté objet et bien qu'il possède des limitations comme l'héritage multiple toutefois contournable par l'implémentation d'une interface au sens POO du terme, il ne faut pas oublier je pense dans la résolution de ton problème que l'intérêt (solidité,performance,maintenance,...) de la POO est justement l'encapsulation. Or j'ai l'impression que ton cahier des charges demande de tout globaliser, ce qui est une abérration, vous en conviendrez aisément.

Si ca peut t'aider donc, voici comment moi je résouds mes problèmes de globalisation tout en gardant prioritaire une structure POO dans mes applis.
- Concernant les constantes de portée globale : Elles sont regroupées dans un ou plusieurs fichier .php par type et/ou catégorie. Aucun problème ici donc au niveau des includes.
- Concernant les variables (dynamiques donc) de portée globale : Le plus sûr niveau sécurité et maintenance est de les implémenter dans une classe (dédié à un fichier .php) qui gèrera le contrôle et les règles de mise à jour et d'accès à ces variables via méthodes et fonctions qui lui sont propres.
- Concernant les fonctions de portée globale générales: De même elles sont regroupées dans une classe (fichier .php dédié) avec tous les avantages que cela comporte.
- Concernant les fonctions de portée globales particulières : Elles sont catégorisées et regroupées dans des fichiers php appelées via require() dans un mode contextuel non automatisé ou automatisé selon.

La globalisation de la classe V de gestion des variables et de la classe F de gestion des fonctions générale est assurée par le stockage de ces deux classes dans $_SESSIONS. Tous les appels énnoncés précédement se font via require et non include (qui est à privilégier en mode débuggage^^) pour renforcer la sécurité. Attention à l'ordre d'appel de tes require sur les pages pour que le parser PHP puisse reconstruire tes classes correctement lors de l'appel session_start().

Donc je ne sais pas si ca peut t'aider, mais je ne voit pas, dans un contexte POO propre et sécurisé, facile à maintenir, comment faire autrement pour gérer les globalisations.

Cordialement,

Jc

Dernière modification par Jc (18-05-2010 06:50:59)

Jc · 18-05-2010 07:07:57

J'oubliais...

Il existe un autre moyen aussi de transcrire une arborescence de site que de le faire via une fonction et une bdd: via l'heritage de classe. Cela est cependant plus complexe, orienté objet à 100%, et difficile à mettre en place sur un code existant non ou peu orienté objet.

Jc · 18-05-2010 10:48:44

Re,

En relisant tes posts j'ai lu ceci

sergnal a écrit :

En effet un autre point du cahier des charges demande la création d'une fonction qui prendra en charge tous les appels de fichiers, c'est ce point qui est problèmatique.

Developpant actuellement un applicatif de type ERP, faut dire que cette approche de ton cahier des charges est assez similaire. Bien qu'il soit aisé de répondre à ton cahier des charges via un "squelette de fonctions" (moins de 10 est une possibilité) pouvant constituer "le noyau" de ton application, il serait bien illusoire à mon sens de répondre à ton cahier des charges via une seule et unique fonction, à moins d'en developper une d'au moins 150-200 lignes de code environ qui ne serait pas très opti à mon avis.

Si tu veux des infos/exemples sur la structure d'une telle fonction/applicatif n'hesite pas à demander.

Dernière modification par Jc (18-05-2010 10:49:52)

Sergnal · 18-05-2010 12:27:33

Bonjour,

Tout globaliser serait effectivement une solution et effectivement aberrant (surtout avec une appli de cette taille), ton système de rangement est bien pensé mais représente un travail certain et sur l'ensemble du code (qui n'est à la base pas spécialement prévu pour du OO).

Sinon je suis très intéressé par ton squelette de fonctions, si tu pouvais m'en dire un peu plus pour que je vois comment fonctionne le concept je t'en serais reconnaissant.

Dernière modification par Sergnal (18-05-2010 12:28:02)

mcAllan · 18-05-2010 18:23:19

hello,

Mon petit grain de sel :

Si dans un premier temps le but est de retrouver les includes, il me semble qu'alourdir le code de tout un tas d'appels de fonctions n'est pas très optimal.
Ceci ne servira qu'une fois (ou guerre plus)...
Pourquoi ne pas faire un petit parseur qui analyserai les pages ?

Cependant, si tu veux aussi récupérer le cheminement de toute l'appli :
Sachant que de toute façon, tu vas reprendre toutes tes pages pour remplacer les includes par "mon_include" pourquoi ne pas à ce moment là simplement ajouter une fonction qui enregistre l'include qui vas être fait.

Un dernier point (après j'arrête de faire le chat noir ):

autre point du cahier des charges demande la création d'une fonction qui prendra en charge tous les appels de fichiers

Étonnant qu'un cahier des charges impose une manière de coder de ce type...

Je pense enfin que tu devrai scinder ta problématique en deux :
-1- Analyser et mettre à plat l'architecture de l'appli.
-2- Nettoyer ou recoder ce qui est nécessaire.

Tout ceci si j'ai bien compris tes soucis évidement.

A+

Jc · 18-05-2010 21:37:29

Bonjour,

Pour essayer de t'expliquer un peu sans tout te dire^^,
Il y a une infinité de façon de concevoir une interface utilisateur sur une couche applicative métier. De cette infinité de façon sera issu une infinité de noyaux possibles pour gérer cette interface utilisateur. Dans tout ceci existe quelques constantes qui relèvent de la méthode / organisation applicative que l'on developpe OO comme tu dis, ou non.

1er cas) On developpe un peu dans l'urgence sans trop de méthode unifiée et globalisée avec pour seul but le rendu souhaité. Chaque développeur pour opti le temps passé dessus va préférer ses méthodes de conception sur lesquelles il est rodé avec une arborescence de fichiers sur laquelle il est le plus à l'aise. De plus en plus le cas, car les critères les plus demandés sont : faire quelque chose qui fonctionne en un minimum de temps, pourvu que ca fonctionne^^, sans regarder plus loin, même si les solutions opensource standardisées freinent un peu se phénomène.
Conséquences : Plus l'application grossie, plus sa structure devient particulière et unique, plus il en est difficile de le maintenir et de le modifier et plus les ramifications sont imprévisibles.

2e cas) On standardise l'interface utilisateur pour qu'elle soit déterministe et facile à maintenir. On découpe la structure des pages en "modules" gérées par leur propre fonction d'affichage. On associe cette structure d'interface à une structure de fichiers, de façon à avoir une similitude hierarchique facile à maintenir.
1) fonction d'affichage page
2) fonction gestion entête
3) fonction gestion menu
4) fonction gestion structure... n
n) fonction gestion pied de page.

Chaque fonction de gestion est déterminée et donc la structure de fichiers appelée est connue et fixe quelque soit le contenu. Toute modification en est immédiatement localisée pour être effective et pertinente.

Ces deux cas sont les deux extrêmes mais les choix initiaux aboutissent toujours à terme aux mêmes conséquences, et les choix intermédiaires aboutissent eux aussi à des conséquences identiques respectivement à ces choix selon qu'ils tendent vers la première ou la seconde.

Le tout est de savoir avant de commencer où l'on veut arriver pour gagner tu temps et de l'argent^^.

Ps:

mcallan a écrit :

Je pense enfin que tu devrai scinder ta problématique en deux :
-1- Analyser et mettre à plat l'architecture de l'appli.
-2- Nettoyer ou recoder ce qui est nécessaire.

Voici des conseils avisés à suivre!

Dernière modification par Jc (19-05-2010 07:37:16)

PHP|Débutant :: Forums

Advertisement

#1 12-05-2010 14:00:12

double fonctions d'include

#2 12-05-2010 23:49:59

Re : double fonctions d'include

#3 17-05-2010 11:07:25

Re : double fonctions d'include

#4 17-05-2010 13:09:20

Re : double fonctions d'include

#5 17-05-2010 14:30:52

Re : double fonctions d'include

#6 17-05-2010 15:15:10

Re : double fonctions d'include

#7 17-05-2010 15:28:47

Re : double fonctions d'include

#8 18-05-2010 06:49:32

Re : double fonctions d'include

#9 18-05-2010 07:07:57

Re : double fonctions d'include

#10 18-05-2010 10:48:44

Re : double fonctions d'include

#11 18-05-2010 12:27:33

Re : double fonctions d'include

#12 18-05-2010 18:23:19

Re : double fonctions d'include

#13 18-05-2010 21:37:29

Re : double fonctions d'include

Pied de page des forums