Thanks for responding. It's been very important - helps "gauge" thinking, how far I am off :)
1. I haven't yet looked at middlewares - will do. 2. custom template tags - I do not see how they can help here (BTW, just completed my first one to loop ranges) 3. Request contexts complexity - as I said, combined with caches they may help, and you seem to think along same lines. After reading some Django docs, it seems that that's what mostly done. Though more elegant than other things, still in my mind far from perfect for a relatively simple thing I am talking about. But that's my Django newbie thinking. 4. "Django application start" vs. "many processes and / or threads as necessary serving your website" Well, that's not unusual - in fact, I cannot think of anything more or less serious that would not do this. Still, something starts the process (and manages it) of spawning threads and processes. In many app servers it is possible to identify along the way a lucky place for a callback(s). 5. Can you please clarify what you mean by "memorization" in "The closest solution would be memorization"? Sounds intriguing. Again, many thanks, Serge On Mar 28, 12:13 pm, bruno desthuilliers <bruno.desthuilli...@gmail.com> wrote: > On 28 mar, 16:58, javatina <serge.i...@gmail.com> wrote: > > > I could formulate my question differently - is there such thing as an > > application context in Django? 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; > > They go into settings.py > > > some of them are more > > dynamic - for example, menu options. > > > 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? > > Yes : custom template tags and middlewares. > > > It seems that although request contexts combined with caching can > > help, it is way too complex for the purposes of initializing the > > application. > > Why so ? > > > Which leads me to another question - is there any callback mechanism > > when Django application starts? > > There's nothing like "Django application start" - depending on the > deployement options, there can be as many processes and / or threads > as necessary serving your website. > > > 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. > > The closest solution would be memoization, but you'll still have at > least one query per process (can't tell about threads). Or using the > cache, which is still IMHO the safest solution. > > FWIW, there are benefits from this "share nothing" architecture when > it comes to scaling. > > My 2 cents -- 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.
