Discussion :

[s.n.a.f.u]

Bonsoir,

Quid de l'architecteure d'une application sur mutualisé avec le ZF 1.8

L'architecture prévue est un fichier index.php dans le dossier './public', et le Bootstrap.php et tout le MVC dans le dossier './application'

Mais cette architecture implique d'avoir la main sur les virtual hosts de apache, ce qui n'est généralement pas le cas sur les mutualisés.

J'ai résolu la question en remontant tout le dossier public à la racine du serveur root.

Ainsi sur ovh, une application MVC avec ZF 1.8 pourrait ressembler à cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
www
    index.php
    img/
    js/
    application/
        Bootstrap.php
        config/
        models/
        views/
        controllers/
 
etc...

Que pensez-vous de cette architecture ?

[Eusebe]

Bonsoir,

Quid de l'architecteure d'une application sur mutualisé avec le ZF 1.8

L'architecture prévue est un fichier index.php dans le dossier './public', et le Bootstrap.php et tout le MVC dans le dossier './application'

Mais cette architecture implique d'avoir la main sur les virtual hosts de apache, ce qui n'est généralement pas le cas sur les mutualisés.

J'ai résolu la question en remontant tout le dossier public à la racine du serveur root.

Ainsi sur ovh, une application MVC avec ZF 1.8 pourrait ressembler à cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
www
    index.php
    img/
    js/
    application/
        Bootstrap.php
        config/
        models/
        views/
        controllers/
 
etc...

Que pensez-vous de cette architecture ?

il me semble que tu n'étais pas obligé de changer l'architecture proposée par le ZF (un dossier public, un dossier application), mais seulement d'adapter le .htaccess pour la réécriture d'URL... Un appel à la page monsite.monhebergeur.com/controleur/action pourrait simplement être redirigée vers /public/index.php et pas simplement index.php.

Mais à part cette remarque, l'architecture que tu proposes ne me choque pas. Il faut simplement ne pas oublier de protéger le répertoire application (avec un .htaccess et deny from all par exemple) à partir du moment où ce répertoire se trouve à un emplacement exposé à l'extérieur.

[s.n.a.f.u]

Mais à part cette remarque, l'architecture que tu proposes ne me choque pas. Il faut simplement ne pas oublier de protéger le répertoire application (avec un .htaccess et deny from all par exemple) à partir du moment où ce répertoire se trouve à un emplacement exposé à l'extérieur.

Ta remarque me fait donc penser à une autre architecture qui serait plus judicieuse : utiliser le répertoire "www" chez ovh en lieu et place du répertoire "public" de l'architecture standard.

Non ?

J'aurais dû y penser avant, c'est con comme l'oeuf de Colomb !

[Eusebe]

Ta remarque me fait donc penser à une autre architecture qui serait plus judicieuse : utiliser le répertoire "www" chez ovh en lieu et place du répertoire "public" de l'architecture standard.

Non ?

Oui, sous OVH il est beaucoup mieux d'utiliser le répertoire www comme public, et de mettre le répertoire application au même niveau que www (donc non accessible directement).