Création de site Blanc avec Symfony sans duplication de code ?

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

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.

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

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

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.

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é.

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).

Tu peut toujours regarder des cotés des filters : http://www.symfony-project.org/refer.../en/12-Filters

Et un petit guide pour mettre en pratique ce que tu cherche à faire : http://www.finalconcept.com.au/artic...cution-filters

J'espère que ca pourra t'aider,
Inarius

@Inarius. Pas bête l'idée d'utiliser les filters. Mais comment gérer là, la notion de réécriture pour certains clients de certains modules ?

Je pense que ca doit être possible de changer les plugins charger dans le filters. Ainsi, on peut par exemple activer les plugins par défaut dans le ProjectConfiguration.
Ensuite dans le filter, en fonction du client, on active tels plugins et désactive tels autres. L'utilisation des autres modules peut ainsi être complétement transparente dans les actions.

EDIT: j'ai trouver un autre document qui pourrait t'aider : http://www.symfony-project.org/more-...fony-Internals

ce lien explique tout le processus de chargement de symfony. Tu y trouveras surement ton bonheur.

C'est pas con, mais j'ai des doutes.

J'ai essayé, pour un projet et suite aux questions posées ici sur un autre problème de ruser dans le même style. Le problème, changer de base suivant le site a atteindre sachant que toutes les bases sont identique. Mon idée, modifier l'objet sfDoctrineDatabase, qui initialise la connexion et renvoie un pointeur, pour qu'il change en fonction de l'utilisateur. Pas de chance, l'objet utilisateur est initialisé après lui...

On va ici ce retrouver dans un cas semblable. Lorsque la méthode ProjectConfiguration::setup est lancée, aucun autre service ou presque ne sont actifs, en fait, seul l'eventDispatcher l'est. Cela va donc impliquer qu'il n'y a pas de configuration active, pas de base de données, pas de connexion, pas d'objet session,... difficile de rassembler les informations sur les plugins à lancer.

Autre problème, le cache. En effet, dans le cache on va y trouver la configuration. Deux choses vont être difficiles à gérer, l'autoload, si tu changes les plugins, tu changes l'autoload, et il pourrait être simultanément différent suivant le site... Et le setting, dans celui-ci sont déclaré les modules actifs des différents plugins, il faudrait donc le modifier à la volée.

Je ne pense pas cela possible. Dommage, l'idée était bonne.

Sinon toujours sur l'idée des filters (je sais je persiste ^^), on peut toujours : charger tous les plugins au démarage et en fonction du site en cours (que l'on a déterminé dans les filters), on peut, par l'intermédiaire de la configuration utiliser des plugins différents.

Par exemple on peut avoir dans le fichier app.yml

Code:

---

1 2 3 4 5 6 7

all: css: site1: main_site1.css modules: site1: plugin1 site3: plugin3

---

et après dans ton code tu auras

Code:

---

1 2 3 4

$this->response->setStylesheet( sfConfig::get('app_css_' . sfContext::getInstance()->get('filter_user')->getSite(), 'default.css') ) // le code est surement faux mais c'est l'idée

---

Donc comme avant, j'ai pas tester et bien sûr il faut appliquer pour vérifier que ca marche...

Inarius

Je vois très bien où tu veux aller...

Mais je vois aussi le mur qui se pointe :mouarf:

Le mur du cache qui sera commun à toutes les applications et impossible à générer. Notamment s'il existe deux plugins différents mais qui couvrent un même besoin, genre gestion simple des membres en standard et gestion évoluée avec un supplément. Certains modules et actions auront le même nom et seront à des endroits différent. Comme tous les sites tournent sur le même cache, il faudrait que l'auto-load puisse faire la différence, mais comment ?

Donc il faudrait aussi modifier le système d'autoload et le système de paramètre pour pouvoir prendre en compte les options. Peut-être réalisable, mais lourd à mettre en œuvre. Quoique... vu la modularité. Il faudrait vérifier si on a accès à la base de données pour l'autoload. Mais on va perdre pas mal en perf. Ou alors créer une arborescence supplémentaire dans le cache pour la configuration avec un cache par client... On va ici avoir à modifier le cœur du framework...