Rails/Django creates the html files and the webserver serves one of those or calls django if there is none that matches the request. For example if someone requests "domain.com/blog/2007/13/12/my-god" than there would be a folder somewhere in the filesystem where the file "/blog/2007/13/12/my-god/index.html" lives in and the webserver serves that file.
I like Option A from sean with server A serving dynamic content and media-server B serving all the assets and mirrored html-files, but woah: I just found a solution that does everything just like rails does with only one server and without mirroring. The key is FCGI. The document-root of the webserver would be the directory where all the site-media and the already-cached pages are and if there is a 404- Error, for example if someone requests a not-cached page, everything's redirected to a dispatcher-script, which calls django and creates a html-page in site-media-directory for the next request. It think this should also have been one of the solutions discussed about 6 months ago. Thanks for all the answers. Julian On 22 Sep., 20:42, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
