> 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.
