No way, even if it's a nice way ... That would completely break my design rules: - Database SHOULD AVOID handle things BUT (BUSINESS) MODEL data (except is we decide to use many schemas or many bases, but that's not my case) - Never setup a process affecting ALL requests or GLOBAL treatment chain to handle SPECIFIC CASES or PUNCTUAL SERVICES.
Thus in your suggestion, we would have to deport the config handling ... on the session. Even if it's handful, that's a bit strange. Whatever, I coded it with Yaml writing. That's a bit boring to test, backup, cache clear and so but this is unobtrusive, and this work. On 5 juin, 10:58, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Just my idea: > > The current behaviour of yml config files is perfect, and it should > stay so. > > You should consider to save those settings in a database and "load" > them in the first request (via filter) in your session. This way those > settings remains on every page. You don't use sfConfig then but create > custom functions in your sfUser class. For example $this->getUser- > > >getSetting('A') > > I think this is the common way to do it ... > > Michael > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---