views:

40

answers:

2

I have a variable called STATIC_URL, declared in settings.py in my base project:

STATIC_URL = '/site_media/static/'

This is used, for example, in my site_base.html, which links to CSS files as follows:

<link rel="stylesheet" href="{{ STATIC_URL }}css/site_tabs.css" />

I have a bunch of templates related to different apps which extend site_base.html, and when I look at them in my browser the CSS is linked correctly as

<link rel="stylesheet" href="/site_media/static/css/site_tabs.css" />

(These came with a default pinax distribution.) I created a new app called 'courses' which lives in the ...../apps/courses folder. I have a view for one of the pages in courses called courseinstance.html which extends site_base.html just like the other ones.

However, when this one renders in my browser it comes out as

<link rel="stylesheet" href="css/site_tabs.css" />

as if STATIC_URL were equal to "" for this app. Do I have to make some sort of declaration to get my app to take on the same variable values as the project? I don't have a settings.py file for the app. by the way, the app is listed in my list of INSTALLED_APPS and it gets served up fine, just without the link to the CSS file (so the page looks funny).

Thanks in advance for your help.

+2  A: 

Variables in settings.py are not available to the templates. What is available to a template is determined by the view that renders it. When the template is rendered you pass in a dictionary which is the "context" for the template. The context is a dictionary of names of variables and their values.

To pass a value from the settings onto the template, you usually have to something like this:

from django.conf import settings
def my_view(request):
    # view logic
    context = {
            'STATIC_URL': settings.STATIC_URL,
            # other template variables here
    }
    # render the template and produce a response

Your STATIC_URL settings seems to be very similar to the MEDIA_URL setting.

MEDIA_URL is made available to all templates via a default context processor. You can do something similar by writing your own context processor. You can take a look at how the default context processors are implemented in the django source to get an idea.

rz
ah, thanks. Adding context_instance=RequestContext(request) to my render_to_response command did the trick. Adding code below since it doesn't render well as a comment.
unsorted
right passing context_instance=RequestContext(request) to render_to_response ensures that all the context processors will be applied.
rz
A: 
def courseinstance(request, courseinstance_id):
    p = get_object_or_404(CourseInstance, pk=courseinstance_id)
    return render_to_response('courses/courseinstance.html', {'courseinstance': p},
        context_instance=RequestContext(request)) #added this part to fix problem
unsorted