That's the discussion I was looking for. Many thanks to you and Bruno Desthuilliers - helps get bigger picture.
On Mar 28, 6:37 pm, Jumpfroggy <rocketmonk...@gmail.com> wrote: > > Basically, the question is - when a web > > application starts there is a number of things that needs to be > > available any time any request. Some of them are really static in > > nature - for example, pagination parameters; > > If these are static values, a good place to put them is in the > settings.py file. I put things like APP_NUMBER_POSTS_PER_PAGE = 10 in > settings.py. As a bonus, they can be overridden with your > local_settings.py file (if you use one). Alternately, you could have > an "app_settings.py" file where you store a bunch of static values, > and just import that file into anywhere it's needed (like your > views.py). > > > some of them are more > > dynamic - for example, menu options. > > If these menu options are application wide, but change often, then I'd > create models to represent them, and store them in the database. If > these are server wide config settings that only change once in a > while, then I'd add them to settings.py (since you probably want those > hardcoded and recorded in your source-control system. If those > settings are per-user, then they'd either be cookies (browser-based), > session vars (session-based), or a settings stored in the user's > profile (ie. stored in DB as a model, the most permanent of the 3). > > > Things get more interesting when such data are read from the database. > > So far what I see is that all that stuff should be places in the > > request context (hopefully cached). It can be done more elegantly if > > custom context processor(s) are created. But we are still rely on > > request contexts. Unless I am missing something? > > In django, contexts are tied to requests. There really isn't an > "application context". If you have a scenario that doesn't fit into > a) settings.py vars, or b) database-backed settings, give us more > details and we can figure out how best to store them. Context > processors are convenient ways to automatically run code for each > request, but I normally just use those to automatically add certain > settings.py vars to each context (like MEDIA_URL, current user, etc). > > > It seems that although request contexts combined with caching can > > help, it is way too complex for the purposes of initializing the > > application. > > What's the caching for? > > > Which leads me to another question - is there any callback mechanism > > when Django application starts? I guess what I am looking is a place > > to make one-time queries, store data in a static member - and viola, I > > have my application context. > > There is no callback mechanism. You can add code to any file > (models.py is a good place), and you can do some tricky python-fu to > make sure it only runs once per process, but that's a bit of a hack. > The real question is - do you really need this? Is there a better > way? > > The most helpful thing would be an example - what is a real-world > value you'd like to store in an "application context", and how would > you use it? Then we can give you some pointers on how to do things > the django way. > > As an aside, I know asp (and other web servers) run as if you have a > single process, with a single set of static vars, and you can pretend > that everything is running as a single application. In django, it's > often better to think about things as "stateless"... ie. there's no > guarantee that there is a single, persistent app running. There's > just your code that runs when needed. For example, if you run apache > + django with multiple processes, then they are separate. Changes to > static vars in one process will not affect the same var in other > processes. So forget all about static classes/objects/variables, as > they're probably inappropriate for most use cases. > > Also, you might be over-optimizing. If you're worried about the > performance hit of loading a set of values for each request (such as > the settings.py values above), you should profile / measure it. The > performance hit of loading such vars would be almost completely > unmeasurable in most cases. So you could just load up such settings > for each request instead of keeping them in static memory, which > really is an optimization (ie. trading memory space vs. CPU & disk > access). -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
