Zend FR

Le set_include_path indique à PHP (oui, c'est bien une fonction PHP) que quand tu fais include ("toto/titi.php"), il va chercher le "toto/titi.php" dans tous les répertoires définis dans le include_path.

Si en général avec le ZF, on inclue le répertoire modèle, c'est parce qu'on a mis dans ce répertoire des fonctions que l'on veut atteindre simplement avec un include("Company/Project/MyClass.php")  (ou un Zend_Loader::loadClass("Company_Project_MyClass")) sans se demander où on a mis les classes de son modèle dans l'arborescence.

C'est juste un truc pratique qu'on fait souvent, mais ça n'est absolument pas imposé par le ZF. Si tu mets ton modèle ailleurs (voire si tu codes sans modèle), tu n'as pas à ajouter ce répertoire dans le include_path.

A+, Philippe

Je rajoute une précision : ne faites pas comme Zend Studio : placez get_include_path() en *premier*, et placez votre ZF en *premier* dans l'include_path de PHP.

Lorsqu'on demande un fichier, PHP cherche dans tous les dossiers de l'include_path en commençant par le premier.
Etant donné qu'énormément de fichiers proviennent du ZF, veillez bien à placer celui-ci en premier dans la pile, de manière à accélérer (et ca peut être significatif sur de la haute charge) l'application

Salut BeRoots,

si tu tiens absolument à utiliser un autoloader, voila ce que tu peux faire d'assez confortable, et en même temps pas trop calamiteux du point de vue des performances :

1] ajouter tous les dossiers "models" à l'include_path

set_include_path(
    '.' 
    . PATH_SEPARATOR    
    . '/peu/importe/library/' 
    . PATH_SEPARATOR 
    . '../application/admin/models/'
    . PATH_SEPARATOR
    . '../application/default/models/'
    . PATH_SEPARATOR 
    . get_include_path()
);

2] enregistrer un autoloader

function modelAutoloader($className) {
    require_once "$className.php";
}
spl_autoload_register('modelAutoLoader');

And voila La fonction spl_autoload_register() va s'ajouter à tout autre autoloader éventuellement enregistré, et aller chercher className.php dans tous les chemins configurés dans l'include_path.

Précision : sous windows, il est possible de se contenter de spl_autoload_register();, auquel cas la spl utilisera sa propre fonction d'autoload, quasi identique à la mienne, à ceci près qu'elle applique l'équivalent d'un strtolower() sur le nom de la classe, et qu'elle cherche également classname.inc. Sous Linux, la suppression des majuscules pose un problème, puisque le système de fichier fait la différence entre clasName.php et classname.php.

Enfin, je précise que ma fonction autoload manque de certaines choses, à commencer bien sûr par une vérification de l'existence du fichier, et qu'il serait également possible de faire des tests peut-être plus performants que require_once() pour éviter le chargement à répétition de classe identiques.

Mais pour de nombreuses raisons, qu'il me semble hors de propos de détailler ici, je pense qu'un autoloader peut être utilisé tel que en développement, mais qu'en prod, si on veut vraiment assurer un max de performances, mieux vaut s'en passer !

Dernière modification par gauthier (02-10-2008 20:31:07)

Bonsoir Olivier,

Et pourquoi ne pas utiliser la fonctionnalité autoload de ZF ? [...] qui est équivalent à écrire la fonction :

Tout simplement parce que ce n'est pas le cas Si tu consultes le source de Zend_Loader, tu verras que la méthode autoload qui s'y rattache est sensiblement plus complexe que celle que tu proposes.

L'approche que je proposais a pour avantage d'être absolument minimale en termes de ressources consommées, même si je suis bien d'accord pour dire que Zend_Loader::registerAutoload() aurait les mêmes avantages, certains contrôles en plus

Résumons la situation :

- si on n'a pas de préoccupations particulière du point de vue des performances ==> Zend_Loader
- si on veut éviter le pire ==> spl_register_autoload() avec un autolaod maison "light"
- si on chasse les millisecondes ==> require() sur chaque classe (on évite require_once()... quitte à faire un if(!class_exists()) quand on a un doute...

Mais soyons clairs : la problématique de performances, du moins à cette échelle, ne concerne que très peu d'utilisateurs ! A moins bien sûr que vous ne fassiez tourner votre serveur web sur un PC en bois fabriqué entre la guerre de 70 et celle de 14

Désolé pour le hors-sujet

la première question 1), si je ne me trompe pas d'interprétation cette fois , c'est la première version qui convient pour suivre le conseil de Julien, à savoir placer le path vers ZF en tout premier de l'include_path. Si tu mets d'abord ".", comme dans ton second exemple, voici ce qui se passe :

// lorsque tu fais ça :
require_once 'Zend/Exception.php';

// php va chercher d'abord à faire :
require_once './Zend/Exception.php';
// ce qui ne fonctionnera pas

// il tentera alors ça ensuite :
require_once '/path/to/ZF/library/Zend/Exception.php';

// et ça ce sera bon

Conclusion : si tu place x chemins avant celui de ZF/library dans l'include_path, PHP devra faire au total x+1 tentatives d'inclusion. En le plaçant en premier, il ne fera qu'une tentative, directement fructueuse
pour la question 2), je ne pense pas être si hors-sujet, dans la mesure ou les fonctions d'autoload s'appuient sur la valeur configurée dans l'include_path, et que d'autre part, l'include_path sert principalement, au moins dans ce contexte, à charger des définitions de classes

Pour la seconde question, disons que j'ai débordé un peu dans l'enthousiasme du moment En espérant avoir cette fois répondu à ta question. Si ce n'est toujours pas le cas, n'hésites pas à me relancer !

ManuB a écrit:

J'ai un plugin en dispatchLoopStartup qui modifie l'include path avec le chemein des modèles selon le module ou je me trouve.....

pourrai t'on avoir un aperçu de ton plugin en dispatchLoopStartup ?
Merci d'avance

Salut Manu,

cette approche, via un plugin, est vraiment intéressante, mais je lui vois tout de même une limitation : quid des modèles génériques (users typiquement, ou encore préférences, etc.) ainsi que des situations où un module doit faire appel à des modèles issus d'autrs modules ?

Cela demande de gérer du cas par cas, ce qui ne semble pas très confortable.

Comment gères-tu ces situations ?

si tu considères un module comme une application à part entière, et qu'elles ne sont pas susceptibles de partager de modèles, en ce cas, oui c'est nickel

Dernière petite question avant adoption du bébé

Si ton bootstrap tu appel un plugin... Ok... Mais pour cela tu doit avoir un définition via set_include_path() pour le ZF avant, nan?

Genre:

/**
* On redéfinit les chemins d'inclusions pour le framework
*/
set_include_path('.'
    . PATH_SEPARATOR . '../0_lib/php/'
    . PATH_SEPARATOR . get_include_path()
);


/**
* Inclusion du loader et appel de la méthode d'auto-chargement de classe
*/
require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();


/**
* instanciation et paramètrage de Zend_Controller_Front (contrôleur frontale)
*/
$front = Zend_Controller_Front::getInstance();
$front->throwExceptions($registry->config->settings->throwexeptions); // true en developpement et false en production
$front->setControllerDirectory(array(
    'default' => 'Application/default/controllers',
    'admin'   => 'Application/admin/controllers',
));

// .... puis enfin on appel le plugin
$front->registerPlugin(new MSAB_Controller_Plugin_PathModels ());

// suite du bootstrap...

C'est ça ?

Merci d'avance

c'est assez bien vue... je pense l'adopté

par contre croit tu qu'il soit possible d'en faire de même pour la définition des chemin vers les controlleurs de chaque module ?

$front->setControllerDirectory(array(
    'default' => 'Application/Default/controllers',
    'admin'   => 'Application/Admin/controllers',
    'admin'   => 'Application/News/controllers',
    'admin'   => 'Application/Forum/controllers',
    'admin'   => 'Application/Blog/controllers',
    'admin'   => 'Application/TarteAuxMirtilles/controllers',
));

je ne sait pas si le singleton $front est accessible depuis un plugin donc au cas où, merci de précisé

sinon on pourrai peut être faire ainsi mais sans plugin:

// on définit le module demander
$module = $request->getModuleName();

$front->setControllerDirectory(array(
    $module => 'Application/'.$module.'/controllers',
));

Qu'en pensez vous ? mieux en module ou au bootstrap ?
perso je prefererrai en module avec un scan de dossier pour en plus definir tout les modules disponible...

Bonjour,
Comme ce thread revient sur la question du bootstrap qui m’intéresse pas mal j’en profite pour mettre au propre mes idées sur la question même si ce ne sont pas des réponses précises à des questions de ce thread  mais en espérant intéresser quelqu’un .   
     
Pour ma part je pense que l’initialisation ne doit pas nécessairement se faire en une seule fois comme c’est le cas si on utilise uniquement un script index.php.    Mais je pense qu’un plugin du type de l’Initializer  n’a pas moins le caractère monolithique d’un boot de type index.php : à l’exécution dans les 2 cas on configure tout ou rien  et en plus il est moins complet car il faut bien que l’enregistrement du plugin Initializer soit faite à l’extérieur du plugin lui-même. Autrement dit on se trouve obligé de configurer l’objet front controlleur en 2 endroits différents alors que centraliser la configuration de ce qui est commun à tous les traitements me
parait aller de soi.
De plus l’initialisation complète d’une application ne me parait pas rentrer naturellement dans les attributions d’un plugin en effet d’après ce que j’ai pu comprendre , les plugins servent essentiellement  à ajouter de la logique à des étapes bien précises de l’exécution du front  (par ex : sécurisation des accés via les acl, interception des erreurs, interception des requêtes, etc..)  or la mission du bootstrap c’est d’une certaine façon  d’initialiser le  processus dirigé par le front controller.     

Il existe une troisième possibilité que j’ai évoquée dans un précédent post sur un autre thread (
http://www.z-f.fr/forum/viewtopic.php?id=1855&p=1) qui est d’utiliser une classe bien spécifique (cad  non prévue actuellement par ZF à ma connaissance)  pour localiser et initialiser les ressources nécessaires aux différents traitements  possibles d’une appli.  On voit fréquemment cette solution sous la forme d’une classe Bootstrap.php mais perso le nom Initializer me va aussi très bien…
Le but de cette classe est comme pour index.php de regrouper en un seul endroit la configuration de tous les
ressources que sont les objets, instances de classes ZF, qui sont utiles à une appli.
La différence c’est qu’à chaque ressource (ou groupe de ressources , j’y reviendrai)  on associe une méthode (statique ou non j’y reviendrai) correspondant elle-même un fichier de configuration  (ini ou xml j’y reviendrai).

L’intérêt c’est d’une part la lisibilité et d’autre part la possibilité d’une configuration à la demande:
-la lisibilité du code réalisant le processus de config est obtenu en ayant une méthode principale disons  run()  qui appelle les initialisations nécessaires à tous les types de traitements d’une appli cad  en particulier tout ce que peut regrouper (cf l’idée de groupe de ressources précédentes) sous le terme de controlleur et de vue.

-la possibilité de configuration à la demande va concerner des initialisations dont certaines sont
identifiables à partir de la requête (par ex la localisation des modèles d’un module) tandis que d’autres
initialisations comme la création d’objet  cache, session, log voire db ou acl ne seront  connues qu’en cour de
traitement.

-un autre avantage noté par Mikaelkael dans un précédent post c’est de ne pas donner à voir son code
s’il y a un problème de parsing dessus. (A condition bien sûr que la classe Bootstrap ne soit pas dans le répertoire  public).

Concernant l’usage des méthodes statiques leur intérêt c’est la rapidité sur une solution de type singleton,
l’inconvénient c’est d’après ce que j’ai pu lire qu’il y a un problème pour étendre une classe avec des
méthodes statiques mais bon si on part du principe que cette classe doit être complète par rapport à tout ce qui peut être à configurer comme ressource ZF dans une appli il suffit de la modifier en fonction des évolutions de ZF ;ce qui de toute façon serait nécessaire mais heureusement pas très courant.   
Je préfère la config avec ini  plutôt qu’avec XML  parce que j'ai remarqué qu’on peut employer dans un fichier ini des constantes définies en php (ce que je trouve intéréssant pour les paths) et que je trouve cela moins lourd qu’xml. 

L’utilisation d’une classe Bootstrap n’élimine bien sur pas le script index.php qui reste vital comme intermédiaire entre le serveur et l’appli et qui reste indispensable concernant l’aspect localisation des ressources (qu’on peut ou non voir comme une partie de la configuration). En effet il faut bien indiquer la localisation de la librairie Zend  et pour cela le seul moyen est l’include_path et cela doit être fait dans le script index.php ou au choix dans une méthode de Bootstrap.php appellé en premier dans la méthode run() (rem : j’élimine à priori la possibilité de définir l’include path dans le php.ini). 

La classe Bootsrap n’élimine pas non plus l’intérêt possible pour la configuration par plugin. Un exemple
étant la classe de Manub pour pointer vers le bon répertoire selon le module ou un autre concernant la localisation des scripts de vue, les css etc..   . Dans ces 2 cas toutefois une certaine étancheité des modules
entre eux s’impose pour reprendre l’idée de Gauthier dans un post précédent sur ce même thread.


PS je n’ai pas mis de code d’une part parce que c’est en chantier et d’autre part parce que je maîtrise pas bien les bbcode.   
Je signale 2 liens pour ceux que cette question interèsse  la dernière évolution de la proposition de Zend_Bootstrap devenue Zend_Application  et la page sur Zym_App auquel il renvoit
http://framework.zend.com/wiki/display/ … n+Scholzen
et le tuto sur zendex  http://code.google.com/p/zendex/wiki/Ze … spatcherFR
Les deux utilisent abondamment XML.

BeRoots a écrit:

@ManuB:

attention, je croit que tu confond $front->setControllerDirectory() et $front->addModuleDirectory()

Sinon en fait, comme le souligne Gchau, j'ai laisser de coté la méthode de plugin car cela arrive trop tard pour mon utilisation (dispatchLoopStartup)... en faite à bien y relechir en faite, je vais même laisser de coté la mise en dossier spécifique par module pour des raison évidente de maintenance (trop de fichier risque d'être en double d'un module à l'autre et cette architecture n'est pas terrible pour maintenir du code non redondant!!)

@Gchau: Sinon, tout re-sortir dans une classe peut être une solution à analyser mais de même, c'est deja trop spécifique pour moi...

Je veut faire en sorte d'avoir un system de gestion multi-appli qui tourne avec des parties communes à toutes les appli et des partie spécifique et facilement maintenable (pas de je redondance donc)...

.

Je ne confond pas.... addModuleDirectory() permet de définir en une seule fois et automatiquement tous les répertoire de tes controleurs


http://framework.zend.com/manual/fr/zen … dular.html voir le paragraphe 8.11.2 Spécification des dossiers de modules.

Je suis typiquement dans ton cas (je pense)..... Plusieurs applications indépendantes dont l'objectif étant d'avoir un seul point d'entrée.

Le fait est que j'ai par contre très peu de choses communes entre mes applis. très diverses (Gestion de bons de délégation pour les IRP(représentant du personnel, CE, DP, DS); Gestion de demande de requêtes infocentre, gestion de demandes de mission à des conseillés... et bien d'autres).

Le seul point commun levé à ce jour est l'authentification à ce point d'accès (utilisation de l'annuaire LDAP). et la gestion de l'accès aux applications...... Tout le monde ne fait pas parti des IRP....

Donc un plugin commun qui me gère l'authentification (650 utilisateurs potentiel d'une même appli., 200 de plus en 2010 mais j'espère ne plus etre la pour le voir.... ;-))...
Un Helper IsMemberOf() qui me permet d'intégrer le lien des applis si l'utilisateur appartient a certain groupe LDAP.

Et différents Helpers, qui me gère "mes ACL" rien a voir avec Zend_ACL....(pas encore...)

pour mon cas l'architecture modulaire s'imposait, et n'ayant pas d'adhérences entre mes applis j'ai choisi de spécifier des dossiers pour mes modèles par modules (application)

Ma solution n'est certainement la meilleure, Très optimisable, je ne suis de plus pas encore un pro de la POO, mais l'important à mes yeux est que la solution choisie réponde a un besoin, ce que fait ma méthode pour mon besoin... et poul'instant çà fonctionne bien.

Le jour où on me dit ou conseil de faire comme cela, que c'est mieux et que CA réponds a mon besoin, je prends....

Malgré les connaissances, l'espérience, j'apprends tout les jours...

Dernière modification par ManuB (08-10-2008 18:32:49)