Discussion :

[boby6killer]

Bonjour,
je viens de débuter sur Synfony et malheureusement, je ne trouve pas de solution a mon problème.

Je souhaiterais pouvoir utiliser une apps et la décliner sous plusieur marques blanches sans duplication de code.

www.monsiteDeBase.com
www.monSiteBlanc.com -> le même site que monsiteDeBase sauf CSS.
www.monSiteBlancCustom.com -> ici en plus de la CSS, on modifie quelques modules

l'idée c'était que tous les site utilise les fichiers de monSiteDeBase pour simplifier la maintenance (un seul fichier a modifier). Mais qu'il puisse aussi définir leur propre implémentation en cas de spécificités particulière à la marque.

je ne sais pas si cette architecture peux être mise en place avec symfony?

Merci

[Michel Rotta]

D'une manière simple je dirais que tous peut-être fais avec symfony, mais parfois ce ne sera pas simple (note, ce que tu veux faire ne sera pas simple, avec où sans symfony).

Tu veux un site qui peut vendre ces services à plusieurs site et avoir la possibilité d'activer, où non, des modules suivant les sites. Ce site aura une seul base de données pour tous les sites clients.

En fait, c'est assez simple. La seul difficulté que je vois, a priori, est la gestion, transformation, du système de route pour qu'il renvoie le nom de domaine en tant que paramètre. J'avais lu un article la dessus (pour des blog genre titi.blog.loc et toto.blog.loc ...) on doit pouvoir adapter au nom plutôt qu'au préfix.

Après, il va te falloir mettre en place l'infrastructure serveur permettant de gérer cela, pas compliqué, mais cela demande des ressources.

[boby6killer]

Bonjour Michel,

Si je comprend bien, symfony permet de mettre en place un système de path inter application.

sur site Base:
module1
module2

sur site 2:
module1 -> redéfinition (on n'utilisera pas celui du site de base)

ainsi quand j'appel le module2 du site 2 c'est celui du site de base qui est utilisé alors que quand j'appel le module1, c'est celui du site 2.

Comment configurer un system de routage commun aux differentes application?

Puis-je créer un fichier routing.yml dans le repertoire config du projet?

Merci

[Michel Rotta]

Diable, je croyais comprendre ce qu'était un module avant d'avoir lu ta réponse

Tu peux envisager d'avoir une application avec un corp et des "modules" (entre guillemet car ce ne sont pas nécessairement des modules au sens symfony du terme). On pourrait plutôt parler d'options. En fonction du type de contrat, accord, ... conclu avec le client on active les modules a partir de droits dans une table. En fonction, on va générer le menu avec uniquement les modules du client. Et on va vérifier au lancement de chaque partie d'un module si l'utilisateur à bien le droit a cette partie qui est élément d'un module.

Par contre, il n'est pas envisageable de créer un module pour un utilisateur uniquement.

Il me semble difficile (mais pas impossible) de gérer plusieurs modules pour une même fonction, je pense que dans un cas pareil, il vaudrait mieux descendre au niveaux de la granularité des modules.

Il faut modifier l'objet route tel que présenté dans The More with symfony book - Techniques Avancées de Routage. Attention, ce n'est qu'une inspiration à prendre, vu qu'ils ne parlent de modifier qu'une partie de l'url. Nous parlons du nom de domaine en entier. Mais l'idée doit être très proche.

[boby6killer]

Actuellement j'ai une solution sans Framework basé sur l'utilisation de la variable include_path.

ainsi, php va chercher les différents fichiers php dans le path et s'arrete des qu'il en trouve un.
/site/site2/;/site/base/

dans l'exemple précédent, pour mon le module1 est trouvé sur /site/site2/module1 donc nous n'irons pas le chercher sur /site/base/.


c'est pour cela que je te parlais de routage global (inter apps).
Dans le cas de site en marque blanche, ils font la même chôse a quelques détaille près. Dans 99% des cas c'est toujours le fichier de base qui est utilisé.

[Michel Rotta]

Sauf que ce qui va nous embêter, c'est le 1% ...

Tu aurais bien la notion de plugin dans symfony. Mais cela nécessiterait une installation par site (ce qui n'est pas plus mal et correspond à ce qui est fait pour les sites dont tu me parles).

Tu crées un plugin pour le site principale. Un plugin pour chaque module "standard" commun à plusieurs client. Et, si un client à une configuration particulière, soit tu installes un plugin directement dans son site (qui prend le pas sur le plugin commun), soit tu re-développes certains des modules des plugin directement pour ce client.

Avantage, du sur mesure au prix du prédécoupé. Ou presque. Aucun problème de routage. Possibilité de séparer les bases de données, ou pas, simplement. Toutes libertés pour les adaptations. Aucun problème pour gérer des css et des images particulières au site.

Total indépendance pour les fichiers téléchargé, pas de risque de "collisions" (suite à un bug, les fichiers de A ce retrouvent chez B !).

Nécessite un serveur dédié pour ton système.

Il doit être possible d'automatiser au maximum (voir complètement) l'installation d'un client (sauf s'il a des développements spécifiques).

Après, tous dépend de la taille et du nombre mais je pense que cette solution colle à un peu tout les profiles (si tu peux avoir un ou plusieurs serveurs spécifiques).