On Mon, 2007-10-22 at 04:18 -0700, Tiger Uppercut wrote:
> Hi,
>
> I'm new to Django, and I'm trying to serve some flex content. I'm
> running mod_wsgi.
>
> In particular, my urls.py looks like this:
>
> (r'^$', serve_main),
So this says you want serve_main() to handle every single URL that is
passed to Django.
>
> views.py looks like:
>
> def serve_main(request):
> return render_to_response('index.html')
>
> index.html looks like:
>
>
>
>
> http://mysite.com/AC_OETags.js";
> language="javascript">
>
> ...
>
> For reference, I've stored AC_OETags.js in my
> DocumentRoot /var/www/mysite.com/AC_OETags.js.
>
> Django is having trouble finding this AC_OETags.js file.
So you've set things up so that Django is handling everything under the
'/' URL? In that case, you have a problem. Django isn't designed to
handle static files. So you have two choices:
(1) Have another domain (could be a separate web server or a separate
virtual host within the same server) responsible for the static content.
This is a popular approach for large sites who can then put dynamically
generated content on one set of servers and static content on another
set. Not suitable for everybody, but certainly an option.
(2) Reconfigure things so that Django is only responsible for serving
everything below, say, /django/ (to pick a random URL prefix). Then
everything that isn't under /django/ will be handled directly by the
webserver without getting near Django. This is is reconfiguration at the
webserver layer, since you are telling the webserver that when it sees a
URL starting with /django/, it should call this thing over here (your
Django process). At the moment, you have something that effectively says
"everything under '/', call this Django thing" and you need to loosen
that up a bit.
You could also set things up in a reverse fashion: specific prefixes are
handled directly (e.g. with specific Location blocks in Apache) and
"everything else" is handled by Django.
For a small-ish setup, particularly, option (2) is the best version.
Only one web server, one domain and a few minutes tweaking the config
files and taking lots of notes so you can reconstruct it next time.
There's also fairly unrecommended option (3), which is to try and serve
the static data through Django by writing a view that reads in a file
and passes it back. However Django is not optimised for that and it's
not a design goal. It will be much less efficient than either of the
previous two choices.
Regards,
Malcolm
--
Always try to be modest and be proud of it!
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
