3π
From looking at your original post it would appear to me that your working at rendering your page from two separate angles.
First, you have {% load staticfiles %}
which will load the templatetags associated with the staticfiles module. Second, inside your link element you are referencing {{ STATIC_URL }}
which gets expanded via context.
From this I would recommend one of the following two courses of action.
1 β Utilize the staticfiles module and the templatetags you loaded in your template.
To do this you should modify your link element to read like this:
<link rel="stylesheet" href="{% static "style.css" %}" type="text/css" media="screen" />
Note that in this instance I have replaced the {{ STATIC_URL }}
with the {% static %}
templatetag. The {% static %}
templatetag takes an argument which is the file you wish to prefix with the static URL, and expands into the complete string.
2 β Make use of context by modifying your view to render with context.
The {{ STATIC_URL }}
variable is made available via request context. There are a number of useful variables that are, that you can rely on to get expanded if you want to utilize them. The trouble is that you have to ensure that you render your template with context which means you would potentially have to change one or more views.
As an example an overly simple view that renders without context would look like:
from django.shortcuts import render_to_response
def index_without_context(request):
return render_to_response("index.html")
While the same overly simple view rendered with context would look like this:
from django.shortcuts import render_to_response
from django.templates import RequestContext
def index_with_context(request):
return render_to_response("index.html",
context_instance=RequestContext(request))
As I stated above, by rendering your template with a RequestContext
you get other variables and such that can be of use so it is a very viable option.
In the end it really depends on where you want to keep the logic that ensures your static files get your static URL rendered correctly at. If you want that logic inside the template itself I would recommend you go with the {% load staticfiles %}
approach and use the {% static %}
template tag. If you prefer to make use of the {{ STATIC_URL }}
variable as well as having other potentially useful variables available then I would recommend modifying your view to be rendered with a RequestContext.
You can read more about the difference between using the context processor or a template tag in the Django docs section about this very topic:
https://docs.djangoproject.com/en/1.4/howto/static-files/#referring-to-static-files-in-templates
1π
Is "home/henk-jan/website/Template/Database"
a valid location? Maybe "/home/henk-jan/website/Template/Database"
instead? Right now the preceding forward slash is missing.
- [Django]-Sending a jQuery POST to a Django View
- [Django]-Django Send emails to all users in the database table
- [Django]-What is the DEFAULT maximum length of TextField Django?
0π
If you are working on the development server, you will want to let Django serve the static content. When you go to production you will have your web server handle serving static content instead.
You will want STATIC_URL
pointing to the path to your static content (in this case it looks like that would be /Template/Database/
. It sounds like you have that working. Now you just need to tell Django to serve static content when in DEBUG mode. See this post: Django MEDIA_URL and MEDIA_ROOT
- [Django]-Django, remove initial space of a template value in a textarea
- [Django]-UnboundLocalError- local variable referenced before assignment β Django
- [Django]-Django admin inline with only one form without add another option