Thanks a lot for your answers! The even greater thing with funky caching is that the webserver only has to serve html (if there is a cached version) and doesn't have to run django. So, django's normal caching is good, but when the server only has to serve already-generated html-files, the whole thing would be even faster. If you know the Rails-blog Mephisto, it does exactly this.
Julian On 22 Sep., 15:10, Tim Chase <[EMAIL PROTECTED]> wrote: > > "you redirect 404 errors to a script, which looks at the requested > > URL, decides whether it should actually exist, and if it should it > > builds the file from the database, saves it to the filesystem, and > > then returns the page to whoever requested it. Next time that URL is > > requested, the static file will be served." (via > >http://weblog.philringnalda.com/2002/11/14/half-baked-and-a-little-fried) > > There are two descriptions of what you might want to do. One is > standard caching (nothing funky about it): yes, Django has a > caching middleware available that can use a smattering of popular > cache backends (memcached being a popular choice). > > http://djangoproject.com/documentation/cache/ > > The other interpretation involves not so much caching-related > concepts as it is "try and guess what the user really meant and > appease them". Sometimes this is a nice thing, and sometimes > this lassos you to an albatross of allowing bogus URLs to persist. > > Fortunately, out of the box, Django can accommodate both, though > the latter takes a little more understanding of the problem-domain. > > If the second is what you mean, at a couple ideas come to mind > depending on what sort of behavior you want. There are two main > types of exceptions of interest: those that map to a view but > the view intentionally raises a 404, and those that can't be > mapped to a view at all, and thus default to a 404. > > 1) make your final entry in your urls.py a catch-all that points > to a view that does what you describe. This is easy, but only > catches unexpected URL schemes. I'm not sure this is quite what > you want though. > > 2) in concert with #1, your views know when they will 404, so > you can just write a custom view that tries to do something > intelligent in a 404 condition. > > 3) use a custom middleware to intercept the response/exception > from a view, and do your jiggering in there. > > Just a few early-morning mid-breakfast thoughts. > > -tim --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---