Zend FR

une idée peut être bête : mais ton param 'module' peut être égale à "modules_societe1" ou "module_societe2", qui correspond a "modules/societe1" ou "modules/societe2".

Pour te donner une autre idée. (C'est très bref)

J'aurai faire un module backend  et un module frontend.
Ton module backend te permet de créer tout ce que tu veux en choisissant pour quel société on le fait (liste des société, avec un id, en base).

Ta partie frontend devrait détecter à partir de l'url, les données de quelle société elle doit récupérer, utiliser un petit système de thème pour gerer le contenu en dur qui peut changer, etc...


Car si j'ai bien compris là tu duplique plein de code identique entre tes différents modules sociétés ?  :s

Salut !

En relisant des posts je croise celui-ci qui correspond de très près à la problématique à laquelle je suis confrontée et sur laquelle je réfléchis depuis quelques semaines maintenant.

Cette problématique j'ai "tenté" de l'expliciter ici ( http://www.z-f.fr/forum/viewtopic.php?id=3611 ) et un peu là (http://www.z-f.fr/forum/viewtopic.php?id=3824), tout en longueur également, mais sans avoir réussir à avoir de retours d'expérience suffisamment partagés pour me lancer définitivement dans une architecture précise (bref, à tatons pour l'heure, me concentrant un peu plus en attendant sur d'autres aspects indépendants de cette archi, mais le temps passe et j'aimerais réussir toutefois à statuer rapidement sur un choix judicieux afin d'esquiver l'expérience que tu viens de traverser avec ce "one shot from scratch" (compassion ?!)).

L'application que je dois mettre en oeuvre est similaire à la tienne : modules (même problème de vocabulaire, "addons" dirais-je du coup) partagés et activables/désactivables, possibilité d'ajout de pages supplémentaires pour une société donnée, ... . Bref en soit énormément de traitements communs mais également des spécificités (éventuelles ou certaines).

La où l'approche est sensiblement différente vient du fait que pour ma part ce n'est pas une application orientée mono-portail multisites mais multiportails multisites (en soit plusieurs portails avec pour chacun plusieurs sites).

Si tu as mis en application ce projet de refonte, pourrais-tu faire part de l'architecture que tu as adopté, en mettant également en avant les contraintes (au sens "erreurs de conception" que tu aurais préférées soulever dès le départ) auxquelles tu as été confrontées ?

En revanche si tu n'as pas encore mis cela en application je suis partant, si ça te dis également, pour confronter nos opinions et discuter allègrement des problématiques auxquelles on peut être confronté à divers niveaux.

Dernière modification par Eureka (20-08-2009 16:30:19)

Salut (et merci pour l'étendue de la réponse !),

J'ai quelques idées / questions, dans la foulée de la lecture. Je t'en fais part :-)

* Détection du site
Je ne sais pas de quelle manière tu sais dans l'index de quel client il s'agit (?) mais pour ma part cela est défini dans un virtualhost, sous forme de variable d'environnement (qui est donc récupérée par index.php qui définiera les constantes de chemins de l'application en fonction de la valeur de cette variable (ex. getenv('client') renverrait 'client1', 'client2', ..., en fonction du virtualhost utilisé donc)

* Relation entre contrôleurs
J'imagine que les contrôleurs spécifiques pour un client (/modules/client/controllers) permettent  par exemple d'ajouter de nouvelles pages pour le site donné, mais penses-tu également à la possibilité qu'ils étendent ou remplacent des contrôleurs par défaut (ceux de /application/model/controllers/) ?

Pour ma part j'y ai réfléchi. La mise en pratique de l'héritage paraît aisément logique, mais la mise en pratique de la substitution un peu moins :
- pour un héritage : peu de problèmes, car le contrôleur du module aura le namespace du module et pourra donc hériter du contrôleur par défaut sans qu'il y ait de conflit de nom ([Default_]IndexController vs Client1_IndexController)
- pour une substitution : comment spécifier à ZF qu'il doit vérifier dans le dossier /controllers du client s'il existe un contrôleur et de l'utiliser (ex: Client_IndexController) et que s'il ne le trouve pas ici il aille prendre celui par défaut ([Default_]IndexController) ?

Les solutions que j'y verrais sont :
- solution 1 : surcharger la méthode instanciant les contrôleurs d'actions en lui demandant de vérifier si un contrôleur existe dans le /module/client et si ce n'est pas le cas prendre celui du niveau d'au-dessus.
- solution 2 (contraignante) : la plus simple mais la moins "sympa" serait que chaque /module/client/ redéfinisse chaque contrôleur par défaut et en hérite, et que pour une substitution on retire simplement le extends [Default_]SameController'. Mais du coup cela implique que chaque client possède tous les contrôleurs définis par défaut... plutôt "lourd" en soit.

* Les modules
D'après ce que je comprends par la suite, les fonctionnellement parlant modules, c'est à dire "auth", "news", ... sont des /modules/ au sens ZF au même titre que "Client1", "Client2", ..., sans distinction particulière dans l'arborescence ?

Et les modèles, que tu dis être des "modules" dans /application/, tu les basculeraient également dans l'arbo /modules/ ? (ils sont fonctionnellement tout aussi commun aux modules clients que le sont les modules "auth" ou "news", non ?

Du coup petite question m'interpelant : des modules dans /application (modèles de site), dans /modules (clients + fonctionnalités), tu les gères tous comme des modules au sens ZF, à savoir utilisable avec Zend_Loader_Module_Autoloader  ?

Au passage, où gères-tu tes /forms ? dans /models peut-être ?

Je viendrais probablement ajouter à cette discussion les mises en applications opérées dans les semaines qui viennent (pour que ce post continue de déborder d'idées et de retours d'expérience)