Questions architecture mvc et autoload

par **juliette** » 13 nov. 2012, 20:57

Ok, je pense comprendre comment tu procède, ça va peut être même me simplifier la vie...
je regarde ça, merci...

par **nhachet** » 13 nov. 2012, 20:32

A titre perso, voilà comment je procéderai :

1. configuration des modules actifs dans le fichier config.php (ou bootstrap.php)

Un fichier du genre peut très bien l'affaire :

$modules = array(
 'blog' => $SITE_DIR . 'modules/blog/class/',
 'membres' => $SITE_DIR . 'modules/membres/class/'
);

2. chargement de l'autoloading via une classe "Loader"

Exemple :

class Loader {
	
    private static $_map = array();
    
	/**
	 * Initialise les données d'autoloading
	 */
	public static function init() {
	
	    // Core
	    foreach (glob($LIBS_DIR . '/classes/*.class.php') as $path) {
	        self :: $_map[strtolower(basename($path))]  = $path;
	    }
	}

	/**
	 * Appelle une classe via l'autoloading
	 */
	public static function call($class) {
	    if (isset(self :: $_map[strtolower($class) . '.php'])) {
	        include self :: $_map[strtolower($class) . '.php'];
	        return true;
	    }
	    return false;
	}
}

On l'utilise comme ceci (pourquoi pas dans le config.php):

Loader :: init();
// Register autoloader
        spl_autoload_register(array(
            'Loader', 'call'
        ));

Je te laisse adapter en fonction de tes besoins, notamment pour la prise en compte du fichier config.php (pourquoi pas passer le tableau $modules à la fonction init() ?)

3. il est conseillé de placer le tableau Loader :: $_map en cache en situation de production.

Du coup l'autoloading est défini une fois pour toute en fonction des modules que tu souhaites activer ou non.

par **juliette** » 13 nov. 2012, 18:09

Ok, j'ai bien compris

Alors maintenant, c'est la que ça ce complique, je revien sur l'aitoload:
1) index.php envois 2 variables $_GET a module.php $_GET['module'] et $_GET['page'] URL: module.php?module=1&page=contact
2) module.php construit l'objet $module avec $_GET['module'] puis inclus l'index.php du module demander
3) Une fois inclus, index.php construit l'objet $page avec $_GET['page']

mon 1er autoload est dans config.php et il indique le chemin libs/classes/

alors ou et comment placé mon 2eme autoload, celui pour chercher la classe membres du module membres pour l'utiliser dans membres par exemple ?

EDIT: l'archi est la suivante...

  WWW/
  ├── LIBS/ <!-- Classes et fonctions primaire de l'application -->
  │   ├── classes/
  │   │   ├── Connex.class.php <!-- Connexion et requetes -->
  │   │   ├── Module.class.php <!-- Choix du module -->
  │   │   ├── Page.class.php <!-- Choix de la page -->
  │   │   └── Pagina.class.php <!-- Pagination -->
  │   └── fonctions/
  │       └── systeme.php
  │
  └── STIE/
      ├── ADMIN/ <!-- Tous ce qui concerne l'admin -->
      │   └── index.php 
      │  
      ├── MODULES/
      │   │
      │   ├── ACCUEIL/
      │   │   ├── class/ <!-- Les classes propre au module accueil -->
      │   │   │   ├── Accueil.class.php
      │   │   │   └── Contact.class.php
      │   │   ├── accueil.php
      │   │   ├── index.php <!-- Utilise $_GET pour afficher la bonne page si non c'est accueil.php -->
      │   │   └── contact.php
      │   │
      │   │ 
      │   ├── BLOG/
      │   │   ├── class/ <!-- Les classes propre au module blog -->
      │   │   │   └── Blog.class.php
      │   │   ├── accueil.php
      │   │   ├── index.php <!-- Utilise $_GET pour afficher la bonne page si non c'est accueil.php -->
      │   │   ├── lire-blog.php
      │   │   └── liste-blog.php
      │   │
      │   │
      │   └── MEMBRES/
      │       ├── class/ <!-- Les classes propre au module membres -->
      │       │   └── Membres.class.php
      │       ├── accueil.php
      │       ├── index.php <!-- Utilise $_GET pour afficher la bonne page si non c'est accueil.php -->
      │       ├── compte-membre.php
      │       └── liste-membres.php
      │
      │
      ├── TEMPLATE/
      │   │
      │   └── model-1/
      │       ├── _css/
      │       ├── _icons/
      │       ├── _img/
      │       └── _js/
      │  
      │
      ├── config.php <!-- Est inclus dans module.php contient l'autoload des classes primaires libs/classes/ -->
      ├── index.php
      └── module.php <!-- Est chargé de trouver et d'inclure le fichier index.php du bon module grace a $_GET -->

par **Mazarini** » 13 nov. 2012, 17:12

D'un autre coté quelqu'un qui s'interroge sur l'organisation de ses fichiers n'aura certainement pas tout faux quelque soit les choix faits.
Chaque organisation a ses avantages et ses défauts.

par **nhachet** » 13 nov. 2012, 17:09

Sache que tu es absolument libre de développer le système qui te convient. C'est bien là le plaisir de l'informatique !

Maintenant, dans un contexte professionnel, le respect des bonnes pratiques et l'utilisation de standards (PSR-0, PSR-1) ont le vent en poupe.
Ton idée de module est une notion qui existe dans les principaux frameworks PHP du marché. Ainsi tu auras affaire à des bundles en SF2, des modules sous Zend et des plugins sous CakePHP. Leur implémentation dans ces frameworks différe, notamment pour l'inclusion des ressources statiques : assets sous SF2 (voir assetic) ; lecteur PHP sous CakePHP.

Bref tu es libre de coder comme bon te semble, tout en sachant que des choses existent déjà. N'hésite pas à jeter un coup d'oeil, histoire de prendre des idées.

par **xTG** » 13 nov. 2012, 16:59

ok mais alors, je ne suis ni dans le vrai ni dans le faux ?
je peux donc, partant du principe que cette construction me convient parfaitement, continuer ma route ?

Bah oui, toute construction est dans le vrai sous certaines conditions.

Si dans 5ans tu t'y retrouves toujours et que tu es la seule sur le projet tu peux faire ce que tu veux (et ce même si c'est incompréhensible comme organisation pour le commun des mortels).
Si par contre dans 5ans le projet accueille de nouveaux devs il te faut une structure qu'ils pourront comprendre ou bien adapter rapidement.

par **juliette** » 13 nov. 2012, 16:43

ok mais alors, je ne suis ni dans le vrai ni dans le faux ?
je peux donc, partant du principe que cette construction me convient parfaitement, continuer ma route ?

par **Mazarini** » 13 nov. 2012, 16:34

Pour moi, il y a 2 principes possible :
1) Faire 1 répertoire par module avec des répertoires par "type" (js, css...)
2) Faire des répertoires par type avec des sous répertoires par module

Je me sais pas qu'elle est la meilleure option entre les 2.

par **juliette** » 13 nov. 2012, 16:06

en fait je fait ça pour apprendre un peut plus et notamment:
- voir l'idée des mvc
- faire un système de module compatible avec d'autres sites du même système
- faire un système d'installation automatique du système avec choix des modules de départ puis des d'ajout de modules
- faire un système de réécriture d'url

je ne m'occupe même pas de l'admin, la vrai but n'est pas la...
je veux que tous ce qui concerne un module soit dans le module.
je veux qu'il y ai 2 types de modules: les espace clients (page web) et les outils (système de votes, sondage a intégré dans les espaces clients)

pour commencer, j'ai une séries de classes pour l'application (connexion, module, page) je commence avec ces 4 la...
- connexion crée les connexion et exécute les requêtes
- module trouve le bon module grâce a $_GET
- page trouve la bonne page grâce a module

ensuite, je veux dans les modules un dossier classes pour celle dédié au module même, ça ressemble a ça:

  WWW/
  ├── LIBS/ <!-- Contient toutes les classes et fonctions de l'applicatoon -->
  │   ├── classes/
  │   └── fonctions/
  │
  └── STIE/
      ├── ADMIN/ <!-- Tous ce qui intervient dans l'admin -->
      │   ├── class/
      │   ├── icons/
      │   ├── css/ 
      │   ├── js/ 
      │   ├── liste-membres.php 
      │   ├── ajout-blog.php 
      │   ├── ajout-tutoriel.php 
      │   └── index.php 
      │  
      ├── MODULES/
      │   ├── accueil/
      │   │   ├── class/
      │   │   │   ├── classe-1.php
      │   │   │   ├── class-2.php
      │   │   ├── exec/
      │   │   │   └── post-message.php <!-- envois les message  -->
      │   │   ├── accueil.php
      │   │   ├── index.php <!-- Est chargé de trouver et d'inclure la page demander au module si non c'est accueil.php -->
      │   │   └── contact.php
      │   │
      │   │ 
      │   ├── BLOG/
      │   │   ├── class/
      │   │   │   ├── classe-1.php
      │   │   │   ├── class-2.php
      │   │   ├── exec/
      │   │   │   └── post-message.php
      │   │   ├── accueil.php
      │   │   ├── index.php <!-- Est chargé de trouver et d'inclure la page demander au module si non c'est accueil.php -->
      │   │   └── list-blog.php
      │   │
      │   │
      │   └── MEMBRES/
      │       ├── class/
      │       │   ├── classe-1.php
      │       │   ├── class-2.php
      │       ├── exec/
      │       │   └── post-message.php
      │       ├── accueil.php
      │       ├── index.php <!-- Est chargé de trouver et d'inclure la page demander au module si non c'est accueil.php -->
      │       └── list-tutoriels.php
      │
      │
      ├── TEMPLATE/
      │   └── model-1/
      │       ├── _css/
      │       ├── _icons/
      │       ├── _img/
      │       └── _js/
      │  
      │
      ├── config.php <!-- Inclus dans module.php, config.php contient l'autoload des classes -->
      ├── index.php <!-- Est chargé d'envoyer des params $_GET au fichier module.php -->
      └── module.php <!-- Est chargé de trouver et d'inclure le fichier index.php du bon module grace a $_GET -->

est ce que cela vous semble cohérent ?

par **Mazarini** » 13 nov. 2012, 15:12

En fait, tu peux mettre le répertoire libs n'importe ou et ajouter ce répertoire dans l'include_path de php.

Personnellement, j'utilise dans l'include_path (dans l'ordre)
- . (rep courant)
- un répertoire pour un site
- un répertoire pour tous les sites d'un domaine
- un répertoire pour tous les sites

J'ai les répertoires :
/srv/domaine.com/www/htdocs (racine du site www.domaine.com)
et je mets libs à 3 niveaux : /srv, /srv/domaine.com et /srv/domaine.com/www
Autrement je peux avoir d'autres domaines en remplacant domaine.com par un autre domaine et d'autres sous-domaine en remplacant www par forum, wiki ou autre chose.

par **juliette** » 13 nov. 2012, 14:52

Alors, que je reprenne pour être sur de bien comprendre:
le dossier www que je nomme est WAMP, le www de wamp...
Voici l'archi modifier:

  WWW/
  ├── libs/ <!-- Contient toutes les classes et fonctions de l'applicatoon -->
  │   ├── classes/
  │   └── fonctions/
  │
  └── STIE/
      ├── admin/ <!-- Tous ce qui intervient dans l'admin -->
      │   ├── icons/
      │   ├── css/ 
      │   ├── js/ 
      │   ├── liste-membres.php 
      │   ├── ajout-blog.php 
      │   ├── ajout-tutoriel.php 
      │   └── index.php 
      │  
      ├── modules/ 
      │   └── membres/
      │       ├── libs/
      │       │   └── classes/ <!-- Les classes dédiés au module -->
      │       ├── exec/
      │       │   ├── deconnexion.php
      │       │   └── valid-connexion.php
      │       ├── accueil.php
      │       └── index.php <!-- Est chargé de trouver et d'inclure la page demander au module si non c'est accueil.php -->
      │
      │
      ├── template/
      │   └── model-1
      │       ├── _css/
      │       ├── _icons/
      │       ├── _img/
      │       └── _js/
      │  
      │
      ├── config.php <!-- Inclus dans module.php, config.php contient l'autoload des classes -->
      ├── index.php <!-- Est chargé d'envoyer des params $_GET au fichier module.php -->
      └── module.php <!-- Est chargé de trouver et d'inclure le fichier index.php du bon module grace a $_GET -->

est ce que je m'n aproche ?

par **nhachet** » 13 nov. 2012, 12:46

En fait, les bonnes pratiques incitent à alléger le webroot (www) au maximum. Cela pour des raisons de sécurité et de logique.

Généralement, le webroot contient les ressources statiques "publiques" (js, css, images) + un fichier PHP qui sert de point d'entrée à l'application.
Hors de ce webroot, tu as un dossier non accessible par navigateur contenant tous tes fichiers applicatifs (contenant tes couches MVC + les librairies).
En général tu as également un dossier "vendor", "library" ou "lib" qui contient les librairies tierces.

Tu as donc cette structure "standards" (le nommage peut être différents) [+ = dossier ; - = fichier] :
www
+ static
++ js
++ css
++ img
- index.php
app
+ models
+ views
+ controllers
vendors
+ lib1
+ lib2
+ lib3

Edit : quelques explications. Le index.php permet d'initialiser le "framework" et appelle un routeur (appelé Dispatcher, Router ou autre). Ce routeur se charge d'analyser l'URL et en déduit un module/contrôleur/action. Le contrôleur prend la main et traite l'action en utilisant la couche modèle (ou non), et en renvoyant une vue.

par **juliette** » 13 nov. 2012, 12:23

Mazarini, don il me manque un étage car www dans mon cas est la racine !

par **Mazarini** » 13 nov. 2012, 10:16

Il y a de bonnes info sur autoload : vos-contributions/autoload-php-avec-san ... 54834.html

Au passage, tu peux sortir lib de www pour que les includes ne soient pas accessible depuis le navigateur.

par **nhachet** » 12 nov. 2012, 23:08

Oui bien sûr. La SPL propose la fonction spl_autoload_register() qui est appelé lors du mécanisme d'autoloading.

Questions architecture mvc et autoload

Répondre

Étendre la vue Revue du sujet : Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload

Re: Questions architecture mvc et autoload