Changes between Version 8 and Version 9 of TemplatePitfalls


Ignore:
Timestamp:
Sep 14, 2005, 10:04:45 AM (19 years ago)
Author:
L.Plant.98@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • TemplatePitfalls

    v8 v9  
    3737I'm posting this to atone for my previous crummy advice on this Wiki page. {{{- garthk}}}
    3838
    39 ''But what if your custom template tags needs access to the HttpRequest object in order to do it's stuff?  For example, if you have a menu or a breadcrumb that depends on request.path, or on the session etc?  Does the DjangoContext object provide access to this in any way?  The only ways I've found are things like subclassing DjangoContext and getting that to use the request to create any data needed for the base templates/custom template tags, but that won't work with generic views AFAIK.  (I'm happy using my current method, as I haven't actually used generic views yet, but imagine I may need to soon). Cheers.''
     39''But what if your custom template tags needs access to the HttpRequest object in order to do it's stuff?  For example, if you have a menu or a breadcrumb that depends on {{{request.path}}}, or on the session etc?  Does the DjangoContext object provide access to this in any way?  The only ways I've found are things like subclassing DjangoContext and getting that to use the request to create any data needed for the base templates/custom template tags, but that won't work with generic views AFAIK.  (I'm happy using my current method, as I haven't actually used generic views yet, but imagine I may need to soon). Cheers.''
    4040
    4141I had a chat to Adrian about that. They haven't yet seen a compelling reason to have {{{DjangoContext}}} stash a copy of {{{request}}}, and indeed it turned out that there was an easy workaround to my use case (access to the request path for my login system). If you have a good use case, submit a ticket. {{{ - garthk }}}
     42
     43''What was your workaround? I think I'm going to need the same thing, as I'll need access to cookies/session for some other login-related common content, which won't use Django's own 'user' functionality.  Cheers - luke''
Back to Top