That's depending on your situation.
I'm handling different clients, different stores and different
settings in an ecommerce app.
When the session is not initialized (first hit), i pull different data
from the db regarding the store, the client and the settings. The
important ones stays in the ses
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
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 cr
Thanks guys for the answers.
We could talk about app's design of course, but trust me, my choices
are thoughtful.
Moreover, I thought it would be interesting to know about this,
globally.
The fact is that I use DB storage to strongly coupled strongly varying
data ... Here, it's just about "almos
On Wed, Jun 04, 2008 at 07:48:55AM -0700, Shinkan wrote:
> I would like to make these parameters values PERSISTENT for all the
> app, until I clear the cache so the parameters can take their original
> app.yml values.
Are you sure these values should not go in some sort of database?
You must wri
Hey there,
this is correct. changes to the config via sfConfig are not
persistent, and they should not be.
After all, that's what all the config yml files are good for. Just set
all your persistent settings in there.
Runtime changes to the sfConfig object should only be done to adjust
for factor
