Préférences utilisateur : best practice?

Version imprimable

10/11/2015, 10h09
foxdie

Préférences utilisateur : best practice?

salut,

je cherche une solution élégante pour répondre à la problématique suivante:

comment gérer les préférences d'une application web sachant que celles-ci doivent être modifiables par l'utilisateur et facilement accessibles en lecture partout (notamment dans les vues)?

Pour ceux qui connaissent wordpress ou prestashop, ces préférences sont par exemple: le nom de la boutique, le titre du site, le n° de tél., le nombre de produits ou d'articles par page, etc...

L'utilisation des fichiers de config (yml ou xml) me semble exclue vu que ces fichiers seront versionnés par GIT, SVN, CVS, ... et que leur modification par l'application risque de poser problème.

Merci pour vos lumières.
10/11/2015, 11h06
phpiste

Bonjour,

après une recherche rapide je suis tombé sur ce lien

https://github.com/egzakt/UnifikDatabaseConfigBundle

je ne sais pas s'il supporte les vues aussi mais normalement il résoud partielement ton souci

pour cela tu peux créer ton propre ExtensionTwig -> récupérer de la base les conf -> exposer d'une façon globale dans les templates

voila

Ahmed
10/11/2015, 11h32
foxdie

salut Ahmed,

Je vais tester, ça à l'air sympa. L'avantage, c'est que le bundle permet de modifier directement les paramètres du fichier app/config/parameters.yml, ce qui permet d'avoir une config de base propre.

Merci pour l'info :mrgreen: !!!

Finalement, c'est beaucoup trop contraignant, il faut vider le cache après chaque mise à jour de paramètre.
J'ai opté pour la solution ci-dessous:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#app/config/services.yml
services:
 
    #un service pour accéder aux paramètres, les modifier, sauvegarder
    dfsettings.settings_manager:
        class: DFSettingsBundle\Services\SettingsManager
        arguments: ["@doctrine.orm.entity_manager"]
 
    #une extension Twig en tant que service, pour accéder aux paramètre dans les vues à l'aide d'un helper du genre: {{ settings("phonenumber") }}
    #le service précédent est passé en paramètre du constructeur
    dfsettings.twig_extension:
        class: DFSettingsBundle\Twig\TwigExtension
        arguments: ["@dfsettings.settings_manager"]
        tags:
            - { name: twig.extension }

Cela vous paraît-il logique?

10/11/2015, 22h58
phpiste

Oui ça l'air logique
sinon pour le cache tu peut le vider "programmatically"
12/11/2015, 12h05
pmithrandir

Citation:

Pour ceux qui connaissent wordpress ou prestashop, ces préférences sont par exemple: le nom de la boutique, le titre du site, le n° de tél., le nombre de produits ou d'articles par page, etc...

Si tu t'en tiens a des données fonctionnelles comme celle la, pas besoin d'un bundle, tu créés une entité config qui contient tes données.
Je te conseille de mettre un cache devant les requetes que tu feras dessus, par exemple de 3-4 minutes. L'utilisateur devra attendre ce temps la pour voir son site mis a jour, mais tu limitera grandement ton utilisation de la BDD.

Maintenant, ton bundle est intéressant si tu voulais changer le nom de la BDD par exemple, ou tout autre parametre dans le fichier parameter.yml. Ca impose un refresh du cache a chaque fois parce que le fichier parameter.yml n'est pas lu en permanence en mode prod.
14/11/2015, 08h21
foxdie

Salut,
Merci pour ta réponse.
J'ai effectivement une entité pour stocker les paramètres en base de données et ces paramètres sont tous orientés métier, donc pas de soucis. Le fait d'avoir un bundle pour gérer les paramètres me permet de pouvoir réutiliser cette fonctionnalité sur d'autres projets.
Par contre, ce qui aurait été intéressant pour moi, c'est que chaque bundle de mon application puisse avoir ses propres paramètres et je puisse les récupérer une liste de parametres dans mon application en fonction des bundles installés.
Mais bon... cela me semble difficilement faisable étant donné que les bundles ne sont enregistrés dynamiquement à l'instar de modules.