|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : août 2009 Messages : 7 ![]() |
Bonjour à tous,
J'ai un petit souci je ne vois pas comment faire bien. Intro : j'ai une appli symfony sur laquelle pointe plein de site: site1.test.com, site2.test.com, site3.test.com... Chaque site à une configuration (une couleur, un titre...) Et ces informations je veux les afficher dans mon layout principale. Or je trouve ça étrange que la seul solution soit le "component", car je devrais faire pour chaque parametre de conf un template en affichant une valeur Du type echo $color pour l'un ou echo $title pour l'autre De plus ça multiplie le nombre de requête... Si quelqu'un peut m’éclaircir je suis preneur, si je n'ai pas été clair je suis complètement disponible! Merci |
|
|
00
|
|
|
#2 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
Tu as un tuto intéressant pour récupérer le nom du site dans l'url ici.
Ensuit je ne suis pas très sur de ce que tu veux faire, mais il me semble que tu souhaite mettre des commandes de style dans ton layout. Je pense que c'est une mauvaise idée. Regarde plutôt à faire une page de style par défaut et de passer une page de style spécifique au site par dessus. Ceci devrait être beaucoup plus souple en terme de mise en page. Pour le titre, tu n'as pas trop le choix. Le problème de symfony 1, ici, est qu'il n'est pas possible de superposer des template, tu as le template au niveau de l'action et le layout. En Symfony 2 et avec twig tu pourrais avoir un nombre théoriquement infini de layout superposés les uns aux autres. Dans ton projet, soit tu veux un layout commun pour tous les sites, soit non. Dans le deuxième cas, tu as la possibilité de choisir le layout lors de l'exécution. Et vu que cela devra être fait pour tous les sites du site (!). Tu as intérêt à créer un filtre (pas un filtre de données, mais un filtre au sens contrôleur dans symfony) et de lui déléguer cette tâche.
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
00
|
|
|
#3 | ||
|
Invité de passage
![]() Inscription : août 2009 Messages : 7 ![]() |
Pour récupérer le sous domaine j'ai utilisé un peu le même principe que ton tuto, mais je n'ai pas utilisé le routing de symfony car je n'y pas vu l’intérêt pour le moment:
Code :
Oui je veux un layout commun pour tous les sites. Mais en gros dans cette table website, il y a 5 éléments de configuration (le nom d'une image, un titre, une couleur...). Des éléments que je souhaite intégrer dans le layout, car commun pour tous les modules. Concerant les filtres, c'est parfait! mais pas dans mon cas!! Le nombre de sous domaines étant illimités. Donc dois je faire 5 components qui retourne qui retourne une dizaine de caractères chacun? Un grand merci pour toutes vos réponses
|
||
|
|
00
|
|
|
#4 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
Il est particulièrement recommandé en symfony de ne jamais utiliser les variables "$_XXX". Ceci empêche notamment le système de test de fonctionner. Je pense que tu as tout intérêt à modifier ton code pour cette partie.
Le filtre n'est pas limité en nombre de choix possible. Mais il n'a d'intérêt que pour l'utilisation des css. Et encore, sous réserve de tests. Pour ta solution qui consiste à intégrer les css dans le layout, je pense que le mieux reste un componment appelé depuis le layout. Dans la partie contrôleur du componment tu récupères les données dans l'objet user où tu les auras stocké à la première requête. Ce qui va éviter les lectures répétitives de la base. Seul inquiétude, est-il possible qu'un même utilisateur (client) consulte simultanément plusieurs sites ? Si oui, il va falloir gérer la chose d'une manière beaucoup plus élaborée. Surtout si un administrateur d'un des sites est aussi visiteur pour les autres... Il ne faudrait pas qu'il puisse administrer les sites de ces camarades...
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
20
|
|
|
#5 |
|
Invité de passage
![]() Inscription : août 2009 Messages : 7 ![]() |
Ok parfait je n'avais pas pensé à ça:
"Dans la partie contrôleur du componment tu récupères les données dans l'objet user où tu les auras stocké à la première requête." Je vais donc faire des component pour chaque avec cette technique. Pour les variables $_..., je vais également suivre tes conseils. Merci pour tout |
|
|
00
|
|
|
#6 |
|
Invité de passage
![]() Inscription : août 2009 Messages : 7 ![]() |
Re!
J'ai marqué résolu mais j'ai parler un peu vite... Tu m'as proposé de "récupérer les données dans l'objet user où tu les auras stocké à la première requête" Ce qui est une excellente idée pour éviter de multiplier les requêtes. Toutefois j'aurais besoin des éléments de conf dans tous les modules et non pas uniquement dans ce component. Ou pourrais je donc faire cet enregistrement dans sfUser? Merci |
|
|
00
|
|
|
#7 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
C'est là que je stockerais l'information.
Mon inquiétude est qu'une personne qui consulte deux "sous sites" différent aura la même session, donc un seul objet sfUser. Et notre beau raisonnement part en fumé. La solution bis serait d'utiliser les principes de caches de symfony pour créer un objet en cache qui contient un array des informations différencient les différents sites. Tu n'as plus alors qu'a attaquer cet objet. C'est viable s'il n'y a pas trop de sites (moins de 50 je dirais). La modification d'un site (nom du cite, création, attribut) entraine la suppression du tableau caché. S'il n'est pas présent, la première requête doit le créer. Mais si je peux expliquer la théorie, je n'ai jamais mis en pratique. Une autre solution serait de différentier les sessions user en fonction des sites. Ce serait plus propre. Mais ici aussi, jamais fais. Et il va falloir entre profondément dans le framework. Par contre, c'est, sans conteste, la solution la plus propre. Solution suivante, s'il vous plais... On en reste à une modification par feuille de style. Le site fait appel, suivant son nom, à une feuille de style qui est chargée après la feuille de style de base. Avantage, c'est fonction du nom du site, donc, pas de lecture en base de donnée, c'est très souple, on peut aller bien plus loin que de changer 2 couleurs et 3 images si on veut. Tu peux aussi envisager de charger un partiel dynamiquement, tu met le nom du partiel en fonction du nom du site. Dans le partiel tu as les données en dur a modifier. Dernière (?) solution. Une variante. Un peu dans l'idée de la css, mais sans css. Le layout fait un include d'un fichier PHP du nom du site. Dans ce fichier figurent les valeurs en dur. Je n'ai pas LA solution. Que des idées de pistes. Je manque d'information sur ce que tu veux faire et des contraintes qui en découlerons pour que je puisse pencher d'un côté où de l'autre.
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
00
|
|
|
#8 |
|
Invité de passage
![]() Inscription : août 2009 Messages : 7 ![]() |
Ouaou!
Pour finir je pense que je vais opter pour la solution sfUser, et concernant le pb des deux sites, et bien je vais mettre les deux en session Code :
$this->getUser()->setAttribute('website', array( 'website1' => $arrayConf, 'website2' => $arrayConf ); Et question peut etre bête mais bon... Le "getUser()->setAttribute" je le met ou? Car je le veux pour tous les modules! Merci |
|
|
00
|
|
|
#9 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
Dans setAttribute tu as un troisième paramètre qui est l'espace de nom pour le stockage. Ceci pourrait permettre de gérer le site.
Le set il faut le mettre à la première initialisation d'une session. Je dirais dans l'initialisation du l'objet sfUser. Reste à trouver comment lui donner les informations à stocker. Si non dans un filtre juste avant le filtre de rendu. Si non (et peut-être plus simple) à la lecture. Tu fais une méthode getParamSite() sur l'objet myUser. Cette méthode regarde si elle a en mémoire (dans l'attribut holder) ce qu'il faut pour le site, si oui, elle renvoie les données, si non, elle les récupères, les stock et les renvoies). A la réflexion, la dernière m'a l'air la meilleur.
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
00
|
Copyright © 2000-2012 - www.developpez.com