If it is Django/Rails who is doing the thing, the server *has* to run it. So it's nonsense speaking about mephisto doing that. The deal would be in apache taking care of it.
El s�b, 22-09-2007 a las 17:26 +0000, julian.bash escribi�: > 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 -~----------~----~----~----~------~----~------~--~---
