On Sun, Oct 9, 2011 at 8:49 PM, Daniel Roseman <daniel@roseman.org.uk> wrote:
Thank you. Thank you. I really didn't noticed this. Checked with vim and found out how poorly intended it looked. I was able to fix with a couple of changed settings in the editor.
I'm writing this because the in-built request.session.varname doesn't provide answer to a dict use-case. I mean I can't do this:
request.session.varname.[some-property] , assuming varname is a dict.
On Sunday, 9 October 2011 20:26:26 UTC+1, Kayode Odeyemi wrote:Hello,<snip>
I'm creating a template tag that will will allow session variables stored as strings or
dict in a view to be available in its template. The syntax is:
{% session_value [view_name] [session_variable] [arg] %}
But at the moment I don't know how I can get Django to stop throwing name errors
on variables/class names that are available. In my code, kwargs, NoReverseMatch are all available, but
Django keeps reporting name errors on them.
Here's the snippet of the code at https://github.com/charyorde/session_value/blob/master/templatetags/tags.py
I will like to know what I'm doing wrong. How do I prevent these constant name errors whenever the
template tag is registered?
ThanksLook again at the format of the code at that link. It clearly shows what is wrong: the try/except block starting at line 58 is badly indented, so it is not counting as part of the `render` method.This appears to be because you have mixed tabs and spaces. *Never* do that. In fact, *never* use tabs - always use spaces.
Thank you. Thank you. I really didn't noticed this. Checked with vim and found out how poorly intended it looked. I was able to fix with a couple of changed settings in the editor.
Plus, line 37 is unnecessary - in fact harmful, because you've already registered the tag with the decorator in line 6. I don't know what happens if you decorate a function twice with the same decorator, but it's unlikely to be helpful.(I won't go into whether or not the whole tag is just an unnecessary rewrite of `request.session.varname`, or your misunderstanding that session variables are in some way related to view names, so we'll leave it there.)
I'm writing this because the in-built request.session.varname doesn't provide answer to a dict use-case. I mean I can't do this:
request.session.varname.[some-property] , assuming varname is a dict.
--DR.--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/1hrQIdPBdyIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
Odeyemi 'Kayode O.
http://www.sinati.com. t: @charyorde
--
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 django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment