Zend FR

Eureka · 19-07-2009 00:51:25

Bonjour,

Je sollite la communauté car j'ai du mal à concevoir une arborescence qui me permettrait d'avoir plusieurs sites dans la même archi Zend.

Plus précisément, ce qui est en la particularité, c'est que j'aimerais avoir un site de base , possédant controleurs, vues, fichiers de langues, modules, modèle de donnée, etc. Ce site de base serait une forme de modèle, un site non-consultable en ligne, sur lequel se baserait des sites qui eux en revanche seraient en ligne.

Ce modèle a pour but une factorisation du code.
Le but que j'aimerais obtenir est que chaque site hérite du site de base, à tous les niveaux, avec la possibilité toutefois de pouvoir surcharger tout ou partie des fichiers pour des cas particuliers.

J'espère être clair en soit.

Je bloque au niveau de l'arborescence la plus judicieuse pour placer le site de base à un niveau où chaque autre site pourrait accéder (plus précisément où un fichier d'un site pourrait hériter du fichier du site de base (extends) ou le remplacer tout simplement (sans héritage)).

Cela implique par exemple qu'un site pourrait exploiter une vue du site de base ou bien sa propre vue si elle existe dans le répertoire du site ; qu'un site puisse utiliser un controleur du site de base, où en hériter pour ajouter une spécificité..

Si ce n'est pas clair je veux bien expliciter des points particuliers (j'ai d'autres petites questions mais là je pense que c'est un bon point de départ)

Libre à chacun de soumettre une idée, quelle qu'elle soit, merci

Dernière modification par Eureka (19-07-2009 00:53:05)

Eureka · 20-07-2009 13:11:53

Bonjour,

Je vais expliciter une partie de mes interrogations.

Désirant baser tous mes sites sur un site de base (et à terme possiblement avoir plusieurs sites de base, donc plusieurs groupements de site se basant chacun sur un site de base) j'aimerais savoir s'il vous parait possible de mettre en place un système qui permettrait :

- de spécifier à l'application d'aller chercher un controleur dans tel répertoire, et dans le cas où il ne le trouve pas d'aller le chercher dans un autre soulève un point particulièr, qui fait que si les controleurs ont les mêmes noms il ne sera pas possible de créer d'héritage entre eux, d'où cette première question : serait-il plus judicieux que chaque site possède autant de controleurs qu'il y en a dans le site de base, avec une simple règle d'héritage ? (ex: IndexController extends IndexbaseController (IndexController n'implémente aucun code en général, mais s'il y a besoin d'une spécificité le code sera prêt pour ça). Si vous avez une idée plus simple d'implémentation je suis tout ouïe.

- en ce qui concerne les vues, ou les forms, la notion d'héritage n'exite pas, peut-on alors spécifier à l'application d'aller chercher une classe dans tel répertoire, et dans le cas où il ne la trouve pas d'aller la chercher dans un autre répertoire ?

L'idée étant vraiment d'avoir un application de base avec toutes ses classes, et de pouvoir avoir des sites pouvant utiliser ses classes ou en les étendant au besoin (héritage) ou en les remplaçant (substitution totale). Il en irait de même pour les helpers d'action, de vue, la gestion des langues, l'héritage de composant Zend (qui serait hérité pour un site donné, mais pas pour les autres), ...

Si vous avez une idée sur tout ou partie de ces points, ou ne serait-ce qu'un soupçon d'idée, n'hésite pas à m'en faire part.

Merci

sekaijin · 20-07-2009 13:49:08

j'avoue ne pas comprendre mais la notion de module n'est-elle pas ce que tu cherche à faire ??

A+JYT

ubini · 20-07-2009 14:56:13

Salut,

J'ai un gros site qui est en fait un backoffice pour chacun de mes coaches et chacun de mes coaches administre lui même trois sites qui sont dépendants du backoffice. Il est clair que je n'ai pas écrit quatre fois le système d'agenda par exemple, alors j'ai tout remonté dans une librairie et j'étends mes controlleurs à cette librairie.

Avant tout j'annonce mon environnement dans mon index.php

Code:

define('MY_ENVIRONNEMENT','produit'); // accepted : (backoffice|produit|business|distributeur)

Code:

class Services_AgendaController extends My_Controller_Action_Agenda
{
     // vide car tout est dans la librairie, mais si une fonction de la librairie ne me convient pas,
     // alors je la remplace ici
}
class My_Controller_Action_Agenda extends My_Controller_Action
{
     // ici tout ce qui concerne les agendas. Avec ma constance MY_ENVIRONMENT et les ACL
     // on peut faire réagir le controlleur comme on veut
}
class My_Controller_Action extends Zend_Controller_Action
{
     // ici mon controlleur général, je mets ici tout ce que je ne peux faire depuis le bootstrap

     public function init()
     {
           // Je rajoute ici un chemin vers mes scriptes de vues communs
           $this->view->addScriptPath(APPLICATION_PATH . '/views/common/');
     }
}

Tu vois que j'ai rajouté un autre chemin pour mes vues. Comme Zend_View va d'abord chercher dans le répertoire du script puis dans celui commun, il est facile pour moi de gérer si je veux une vue spéciale ou non en la créant ou non

Je suis comme Sekaijin, je comprends pas tout mais je pense que tu cherches simplement à te faire ta propre librairie ZF non ?

++

lesauf · 20-07-2009 19:39:12

La bibliothèque 'Fast' de Sekaijin est justement sur le meme principe que ce qu'explique Ubini, à ceci près que My_Controller_Action_Agenda s'appele plutot Fast_Controlleur_Crud. C'est le crud sur lequel je travaille depuis.

Lesauf

Eureka · 20-07-2009 21:22:27

Bonsoir !

Déjà, merci pour vos réponses.
Je constate que j'ai été un peu brouillon dans les explicitations précédentes (bien que la réponse d'ubini s'y approche fortement (ou totalement mais je n'en ai pas pleinement conscience avec les éléments en main).

Je vais tâcher de remédier à cela (n'éyant pas envie de mal concevoir les applications dès le départ et qu'un correctif global devienne très difficile à implémenter par la suite).

1er POINT: BESOIN

Soit, via un exemple argumentatif : j'aimerais pouvoir mettre en ligne 10 sites, ayant chacun leur propre nom de domaine. Mais ces 10 sites sont sensés avoir les même fonctionnalités (à savoir des plugins activables / désactivables, une même charte graphique, même navigation).

J'aimerais donc réussir à mettre en place via ZF une application que chaque site pourrait utiliser, avec une base de donnée commune (dont les occurences en base seraient toutefois spécifiques à chaque site).

Voilà, c'était l'idée de base : une site type permattant l'exploitation de plusieurs sites.

Mais... mon désir est de pouvoir toutefois, pour tout ou partie des sites, de pouvoir surcharger l'existant voire l'écraser. En soit le site 1 aura une charte graphique personnalisée, le second aura un modèle de données peut-être un peu plus étayé avec donc des traitements spéciques dans des controleurs (héritage du site de base pour ajout de fonctionnalité), ou des pages supplémentaires (ajout de controleur qu'au niveau du site donc) et tout autre substitution que l'on pourrait imaginer.

Dernière chose, j'aimerais pouvoir créer plusieurs "site type", afin de pouvoir 10 sites basé sur un site type donné, 5 autres sur un autre site type (avec des BDD différentes pour chaque site-type probablement), et même peut être la possibilité d'avoir un super site-type avec quelques données génériques, dont découleraient les site-types, desquels découleraient des sites à mettre en ligne.

2ème POINT : VOS REPONSES

Concernant les "modules", j'ai appréhendé cette notion comme une mini-application au sein d'un site, et pas comme un site à part entière. Peut-être me suis-je mépris à ce sujet. Si un module peut satisfaire à mon besoin pourquoi pas !

Concernant l'exemple de l'agenda, je trouve l'idée très bonne. J'aurais également besoin d'un agenda comme "plugin" donc la problématique colle bien.

J'avoue que pour l'ajout de chemins de vues et la notion de surcharge dans Service_Agenda ça répond très bien au type de développement auquel je vais être confrontés (du moins je pense).

En revanche la présence de "controler" dans la 'librairy' ça me fait bizarre. Jusqu'à maintenant j'associe beaucoup un 'controler' à une page ou un ensemble de page (peut-être que je me méprends à nouveau). Dans ton cas, ubini, ton controler est appelé par l'URL et va générer une page injectant l'agenda au sein d'un layout ? Ou est-ce qu'à partir d'un 'controler' dans 'application' tu appelles une action de ton controler Agenda pour rappratier l'agenda au sein d'une vue (vue qui regroupe peut-être plusieurs autres éléments) avant d'être injectée dans un layout ?

La notion de librairie est intéressante soit, mais du coup je ne sais pas trop si je dois avec un composant pour chaque 'site-type', ou si chaque site-type devrait être dans un dossier du dossier /application au même titre que les sites implémentables.

Ouf ! (en espérant avoir réussi cette fois à mieux posé mon besoin et mes questionnements liés)

Eureka · 21-07-2009 15:21:44

Edit: un site pourrait être associé à un nom de domaine ou à un sous-domaine. Cela dit je ne pense pas que cela soulève de problématiques particulières quand au développement de l'application.

Dernière modification par Eureka (02-08-2009 16:15:56)

Eureka · 02-08-2009 16:18:32

Je ne sais pas trop qu'ajouter ou quel point éclaircir.

Parmi vous certains ont déjà mis en ligne plusieurs sites se partageant une même arborescence (avec des notions d'héritage avec des controleurs communs ou substitution de fichiers de vues communs) ?

Ma problématique devenant urgente désormais, s'il y a des points que je vois éclaircir afin que mon questionnement soit plus clair pour vous, alors n'hésitez pas à me dire quel(s) élément(s) je dois expliciter...

Dernière modification par Eureka (02-08-2009 16:20:31)

Eureka · 04-08-2009 14:55:22

Bonjour !

Après relecture de l'ensemble un cas pratique (factice) serait bien plus explicite : je veux créer des sites de... clubs de natation.

Dans un premier temps je veux créer un site basique : Site_Natation.
Il contiendra des contrôleurs, des vues, des aides d'actions et de vue, etc...
Il possèdera une page d'index, une page de présentation du club avec un simple texte, une liste des membres de l'équipe du club, un page de de contact.
Ce site sera une base pour créer des sites pour divers clubs !

Il y aura le site de l'Olympique de Pellouailles (http://www.olympique-pellouailles.ex).
Je veux qu'il soit calqué sur le site basique Site_Natation, à la différence que le graphisme sera totalement différent. Donc les vues devont être remplacées pour ce site.

Il y aura le site NC Charcé (http://www.fc-charce.ex).
Je veux qu'il soit calqué sur le site basique Site_Foot, en gardant le même graphisme (pas de surcharge donc). En revanche sur la page de présentation je veux ajouter un petit agenda (plugin activé pour ce site).

Il y a aura.. pleins de sites ! Chacun bénéficiera du Site_Natation, mais chacun pourra bénéficier de particularité (plus de pages pour certains, donc ajout de controleurs spécifiques et vues pour un site donné, plus de plugins sur d'autres, un graphisme spécifique pour l'un, etc....).

Quel pourrait être la meilleur approche pour pouvoir faire bénéficier un site d'un club du site basique avec possibilité de surcharger tout ou partie du site basique ?

Idée d'arbo (en partant du principe qu'il pourrait y avoir d'autres sites basiques pour d'autres sites de sport, à savoir Site_Football, Site_Tennis, ...) :

/public
/index.php

/librairy
/librairy/Zend/

/application
#commun à tous les sites basiques
/application/CommonBootstrap.php
/application/config/
/application/controllers/
/application/views/
/application/models/

#site basique natation
/application/natation/
/application/natation/SitebaseBootstrap.php
/application/natation/config/
/application/natation/controllers/
/application/natation/views/
/application/natation/models/

#site natation olympique de pellouailles
/application/natation/olympique_pellouailles/
/application/natation/olympique_pellouailles/Bootstrap.php
/application/natation/olympique_pellouailles/config/
/application/natation/olympique_pellouailles/controllers/
/application/natation/olympique_pellouailles/views/
/application/natation/olympique_pellouailles/models/

#site natation NC Charcé
/application/natation/nc_charce/
/application/natation/nc_charce/Bootstrap.php
/application/natation/nc_charce/config/
/application/natation/nc_charce/controllers/
/application/natation/nc_charce/views/
/application/natation/nc_charce/models/

#site basique football
/application/football/
/application/football/SitebaseBootstrap.php
/application/football/config/
/application/football/controllers/
/application/football/views/
/application/football/models/
#sites football .....

Voilà clairement la problématique à laquelle je suis confronté. Pouvoir faire bénéficier chaque site du modèle parent tout en pouvant respécifier (par héritage ou substitution) certains éléments.

Un peu long, mais en souhaitant avoir été moins brouillon du coup.

Edit: ajout des [*]Bootstrap.php à chaque niveau (héritage)

Dernière modification par Eureka (04-08-2009 18:11:36)

booradley · 18-08-2009 09:45:48

J'ai moi aussi plusieurs sites identiques dont diffère seulement l'url et la charte graphique.
Ils utilisent donc les mêmes controlleurs, et éventuellement les mêmes vues et la même base de données.
Dans mon dossier /public, j'ai:
/public/site1.com/
/public/site2.com/
Et dans chacun de ces dossiers, un htaccess et un fichier index.php qui fait appel à un boostrap (identique ou non) qui se charge de charger les modules nécessaires.
Je n'ai donc pas besoin de squelette de site ou de site "virtuel" dont dériveraient les sites 1 et 2.
Si les vues des 2 sites différent, tu peux dans chaque module avoir des sous dossiers:
/module1/views/site1.com/
/module1/views/site2.com/

david

Dernière modification par booradley (18-08-2009 09:47:47)

Eureka · 18-08-2009 10:22:13

Intéressant d'avoir un concept similaire

Pour le public j'ai opté pour la même approche que toi.
En ce qui concerne l'applicatif, ta méthode permet une modification pratique des fichiers de vues, ce qui est excellent, mais as-tu été confronté à un besoin de modification au cas par cas du code d'un controleur, ou d'un modèle de données, ou d'une aide d'action ou de vue pour un site donné ? C'est dans cette optique que je me suis dit qu'il pourrait être intéressant d'avoir un site de base dont hériterait chacun, et qui permettrait au fil éventuel des besoins de modifier l'application pour un client donné.

booradley · 18-08-2009 10:32:16

Si la modification du code du controlleur est mineure, j'intègre un switch case sinon je crée soit un controlleur différent soit une action différente au sein du même controlleur.
a+

Eureka · 18-08-2009 11:17:56

Dans un sens c'est plus abordable effectivement.

Pour ma part j'ai mis en place la méthode de surcharge des controleurs sur 3 niveaux (et de toutes les classes au final à vrai dire, models, helpers, ...).

Lors de l'appel d'un site Y, je défini un namespace Common pour le dossier contenant l'application commune à tous les "portails", puis un namespace Portal pour le portail concerné par le site et du coup pour un controleur donné j'ai :

Code:

class CommonController
{ // code commun à tous les sites de tous les portails }

class PortalController extends Common_Controller_IndexController
{ // code commun à tous les sites du portail en cours }

class IndexController extends Portal_Controller_IndexController
{ // code du site }

Cette approche à l'avantage de permettre :
-> d'avoir du code dans "Common" qui se répercute pour tous les sites et éventuellement une surcharge dans "Portal" pour tous les sites du portail en cours, voire une surcharge dans le site.
-> de pouvoir ajouter des pages spécifiques pour un portail ou un site en supprimer respectivement l'héritage vers Common ou Portal (spécifique, donc pas besoin de controleur à un niveau 'haut')

En revanche l'inconvénient auquel je suis confronté, est que :
-> chaque site doit posséder les controleurs (classes) qui mettent en place l'héritage. Du coup chaque classe doit être présente à tous les niveaux de l'arborescence même si elle est vide pour les niveau 2 et 3.

Je n'ai pas trouvé de moyen(s) de faire en sorte de n'avoir qu'un seul controleur dans 'Common' sans devoir créer ceux des niveaux en dessous.

Une solution pourrait être de surcharger la classe gérant l'appel aux controleurs, qui se chargerait de vérifier l'existence des controleurs, à savoir : s'il n'existe pas de classe IndexController (site), qu'il utilise alors la classe Portal_Controller_IndexController si elle existe, sinon Common_Controller_IndexController.

Je n'ai pas évalué les effets de bord, mais me viennent à l'esprit :
-> les vues ne seraient pas trouvées dans /views/ en fonction du nom du controleur puisqu'il peut y avoir 3 noms différents (à moins de surcharger les méthodes de rendu qui hôteraient les termes Common_Controller_ et Portal_Controller_ pour chercher le fichier de vue "index", ou, alternative, spécifier le chemin du script manuellement dans chaque action dans les controleurs)
-> y en a sûrement d'autres...

Et cela ne se limite pas aux controleurs, sont surchargés ainsi :
-> par héritage : les helpers d'actions et de vues (comme les controleurs) et éventuellement les modèles (en cours de réflexion si utile ou pas)
-> par fusion : les fichiers de langues et de configs
-> par substitution (prend via méthode FIFO le premier fichier trouvé selon l'ordre Site > Portal > Common) : les layouts et les vues

Si quelqu'un a des arguments pour et/ou contre quant à la notion d'héritage sur 3 niveaux, ou sur la gestion de surcharge de recherche des controleurs, je suis tout ouïe (avant de trop m'avancer dans cette démarche car il sera probablement difficile de revenir en arrière par la suite)

booradley · 18-08-2009 13:58:21

Cette facon de "surcharger" des controllers n'est pas dans la philosophie de Zend.
Un controller sert uniquement à .... contrôler.
Le nombre de ligne de codes n'excede généralement pas une vingtaines de lignes.
En effet tous les traitement métiers DOIVENT ETRE DEPORTES dans des ActionHelpers ou aides d'action.
Voilà comment tu devrais t'y prendre:

Code:

<?php
class Module72_Controller45Controller extends Zend_Controller_Action   
{   
  public function indexAction()   
  {
if($site=="956") {
 $result = Module123_Helper_TraitementSite956::direct();
} else {
 $result = Module123_Helper_TraitementAutresSites::direct();
}
}
....
}
?>

David

Dernière modification par booradley (18-08-2009 13:59:08)

Eureka · 18-08-2009 15:25:26

Vraiment ?

Je trouve la cohésion extrêment faible au sein du contrôleur du coup.

En partant dans cette optique, tout traitement aurait donc lieu dans des helpers.

Mais ça peut devenir rapidement un grand bazar au sein des répertoires, si un même helper se voit être copié/collé(+modifié) 10 fois pour subvenir au besoin de tel ou tel site, non ?

De même qu'un controleur qui doit être remanié pour un site donné va posséder des traitements qui n'ont pas grand chose à voir ceux des autres sites.

S'il y a d'autres retours d'expériences ou idées le débat est lancé Merci en tout cas pour cette idée à laquelle je n'aurais osé penser.

booradley · 18-08-2009 15:32:47

Plus on veut rendre l'application modulaire, plus le nombre de fichiers va augmenter et leur contenu diminuer pour ne contenir que des traitements unitaires.
Un helper d'action peut appeler de nombreux autres helpers d'actions qui chacun réalisera un traitement unitaire et qui sera réutilisable par d'autres controllers/actions ou d'autres helpers.

Eureka · 18-08-2009 15:57:55

En effet ça colle bien à l'esprit modulaire.

En prenant un cas pratique : un espace perso.

Si j'ai un controleur qui se charge d'afficher l'espace perso, et que :
-> sur un site X il faille afficher un petit agenda et une liste d'articles favoris
-> et sur un site Y il faille un petit agenda, une liste de blog et une carte google map

Judicieusement faudrait-il alors :
-> appeler dans l'action du contrôleur pour le site X une aide d'action spécifique (qui se chargerait à son tour d'appeler un helper pour l'agenda et un pour l'article) et pour le site Y une autre aide d'action (qui se chargerait elle d'appeler 3 helpers pour ramener ses contenus) ?
OU
-> appeler directement dans l'action les 2 helpers du site X et les 3 helpers du site Y ?

Zend FR

#1 19-07-2009 00:51:25

Multi site avec héritage d'un site

#2 20-07-2009 13:11:53

Re: Multi site avec héritage d'un site

#3 20-07-2009 13:49:08

Re: Multi site avec héritage d'un site

#4 20-07-2009 14:56:13

Re: Multi site avec héritage d'un site

Code:

Code:

#5 20-07-2009 19:39:12

Re: Multi site avec héritage d'un site

#6 20-07-2009 21:22:27

Re: Multi site avec héritage d'un site

#7 21-07-2009 15:21:44

Re: Multi site avec héritage d'un site

#8 02-08-2009 16:18:32

Re: Multi site avec héritage d'un site

#9 04-08-2009 14:55:22

Re: Multi site avec héritage d'un site

#10 18-08-2009 09:45:48

Re: Multi site avec héritage d'un site

#11 18-08-2009 10:22:13

Re: Multi site avec héritage d'un site

#12 18-08-2009 10:32:16

Re: Multi site avec héritage d'un site

#13 18-08-2009 11:17:56

Re: Multi site avec héritage d'un site

Code:

#14 18-08-2009 13:58:21

Re: Multi site avec héritage d'un site

Code:

#15 18-08-2009 15:25:26

Re: Multi site avec héritage d'un site

#16 18-08-2009 15:32:47

Re: Multi site avec héritage d'un site

#17 18-08-2009 15:57:55

Re: Multi site avec héritage d'un site

Pied de page des forums