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

Reply via email to