Changes between Version 5 and Version 6 of TemplatePitfalls

09/06/05 07:23:52 (10 years ago)

Atonement for previous crummy advice


  • TemplatePitfalls

    v5 v6  
    27 == Context variables and template inheritance ==
     27== custom context variables for generic views ==
    29 It's handy to define a method each view can call to fill in its {{{Context}}} with the right variables. If you're inheriting templates, you should also do the same with the method. I've ended up with an {{{app_vars}}} method in each app's views module which calls {{{site_vars}}} in the site.
     29More advanced versions of the base template (mine is {{{base.html}}}, following the model set in the administration interface) might need a consistent set of context variables generated on the fly based on the identity of the current user, what they're doing, what's happening elsewhere on the site, and so on.
    31 {{{site_vars}}} goes in {{{sitename/views/}}} if you're trying to match the default shape of the application namespace, or in {{{sitename/}}} if you're flattening it:
     31If you're using generic views, though, there's no obvious way to make these context variables available.
    33 {{{
    34 def site_vars(request, **kwargs):
    35     """Determine context variables for the site's base template."""
    36     user = request.user
    37     is_anonymous = user.is_anonymous()
    38     if is_anonymous:
    39         username = name = '(anonymous)'
    40     else:
    41         username = user.username
    42         name = user.get_full_name()
    43         if not name:
    44             name = username
    45     vars = {
    46         'is_anonymous': is_anonymous,
    47         'name': name,
    48         'username': username,
    49     }
    50     vars.update(kwargs)
    51     return vars
    52 }}}
     33The solution is to use [ custom template tags], which can modify a page's context variables on the fly.
    54 A custom version of {{{app_vars}}} goes in each {{{sitename/apps/appname/views/}}} (or, if you're flattening the namespace, {{{sitename/apps/appname/}}}):
     35If your needs are middling simple, or you don't want to have to write your own custom template tag from scratch, I've developed a generic option: [ vars],  which defines a fairly generic {{{pushvars}}} tag that calls the function of your choice and pushes its results into the current context.
    56 {{{
    57 def app_vars(request, **kwargs):
    58     """Determine context variables for the application and site base templates."""
    59     vars = {} # set your app variables here
    60     vars.update(site_vars(request, **kwargs))
    61     return vars
    62 }}}
     37I'm posting this to atone for my previous crummy advice on this Wiki page.
    64 The keyword arguments let you define additional useful variables for your page without having to further manipulate the dictionary: just keep piling on the arguments to {{{app_vars}}}. Let's say your base template likes to have a {{{title}}} variable available to it:
    66 {{{
    67 def index(request):
    68     """View the appname index."""
    70     # Customise the app variables the hard way
    71     vars = app_vars(request)
    72     vars['title'] = "Index"
    74     # Or, the easy way
    75     vars = app_vars(request, title="Index")
    77     # Load the template, construct the context, and render one against the other:
    78     t = template_loader.get_template('appname_index')
    79     c = Context(request, vars)
    80     return HttpResponse(t.render(c))
    81 }}}
     39{{{- garthk}}}
Back to Top