is_safe problem
So my template looks like: {{ group|caps }} (`group` is a Model object
and the `caps` filter just capitalizes the first letter) and I'm stuck
with double escaping.
The problem is, that it still gets double-escaped. Django's
FilterExpression checks to see if the incoming object is SafeData, but
at this stage it is a Model object - it hasn't be translated to its
__unicode__ value yet.
I thought I had found the solution by applying the stringfilter
decorator to my filter but that doesn't help either, because that
still only gets applied after FilterExpression does its check.
I can't really see how to overcome this problem in the template
parser. Malcolm?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
PS: I've never even noticed the built-in `capfirst` filter until just now, but mine was pretty much identical. The built-in one doesn't solve this problem either. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: is_safe problem
Hi Chris,
SmileyChris wrote:
> So my template looks like: {{ group|caps }} (`group` is a Model object
> and the `caps` filter just capitalizes the first letter) and I'm stuck
> with double escaping.
>
> The problem is, that it still gets double-escaped. Django's
> FilterExpression checks to see if the incoming object is SafeData, but
> at this stage it is a Model object - it hasn't be translated to its
> __unicode__ value yet.
>
> I thought I had found the solution by applying the stringfilter
> decorator to my filter but that doesn't help either, because that
> still only gets applied after FilterExpression does its check.
VariableNode always uses force_unicode to solve the problem that you
describe. It seems that FilterExpression is guilty:
In django/template/__init__.py, class FilterExpression:
def resolve(self, context, ignore_failures=False):
try:
obj = self.var.resolve(context)
except VariableDoesNotExist:
if ignore_failures:
obj = None
else:
if settings.TEMPLATE_STRING_IF_INVALID:
global invalid_var_format_string
if invalid_var_format_string is None:
invalid_var_format_string = '%s' in
settings.TEMPLATE_STRING_IF_INVALID
if invalid_var_format_string:
return settings.TEMPLATE_STRING_IF_INVALID % self.var
return settings.TEMPLATE_STRING_IF_INVALID
else:
obj = settings.TEMPLATE_STRING_IF_INVALID
for func, args in self.filters:
arg_vals = []
for lookup, arg in args:
if not lookup:
arg_vals.append(mark_safe(arg))
else:
arg_vals.append(arg.resolve(context))
if getattr(func, 'needs_autoescape', False):
new_obj = func(obj, autoescape=context.autoescape, *arg_vals)
else:
new_obj = func(obj, *arg_vals)
if getattr(func, 'is_safe', False) and isinstance(obj, SafeData):
^
obj = mark_safe(new_obj)
elif isinstance(obj, EscapeData):
obj = mark_for_escaping(new_obj)
else:
obj = new_obj
return obj
In the two places marked with , you need to test force_unicode(obj)
instead of obj (in the isinstance test). But this means calling
force_unicode() twice (once in VariableNode.render, once in
FilterExpression.render), not nice.
I cannot dig into this more since I'm in a hurry, hope this helps a bit
before Malcolm can come up with a proper solution.
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
SmileyChris wrote: > The problem is, that it still gets double-escaped. Django's > FilterExpression checks to see if the incoming object is SafeData, but > at this stage it is a Model object - it hasn't be translated to its > __unicode__ value yet. As far as I understand the thing *now*, it shouldn't make any difference because neither your model object nor its __unicode__ is SafeData and thus it needs escaping anyway. is_safe=True set on capfirst doesn't do anything to this value because it wasn't SafeData before capfirst and shouldn't become safe after. But since you're saying about double escaping when you have only one filter I suppose you're trying to return escaped data from __unicode__? If yes then this is a problem. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: is_safe problem
On Nov 22, 8:46 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > The problem is, that it still gets double-escaped. Django's
> > FilterExpression checks to see if the incoming object is SafeData, but
> > at this stage it is a Model object - it hasn't be translated to its
> > __unicode__ value yet.
>
> As far as I understand the thing *now*, it shouldn't make any difference
> because neither your model object nor its __unicode__ is SafeData and
> thus it needs escaping anyway.
I should have clarified that for this model, I have it's __unicode__
method return a safe string:
return mark_safe('%s (%s contacts)' %
(escape(self.name), self.contacts_total)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
SmileyChris wrote:
> I should have clarified that for this model, I have it's __unicode__
> method return a safe string:
>
> return mark_safe('%s (%s contacts)' %
> (escape(self.name), self.contacts_total)
Hm... I give up then :-). From my looking around the code I think it
should behave as you expect because capfirst being a stringfilter should
call force_unicode on the object and return a SafeUnicode instance.
P.S. However I think you try to shoot yourself in the foot by tying
general unicode representation of an object to work only for HTML. I'd
rather leave it to some special filter.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
On Nov 22, 10:48 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> P.S. However I think you try to shoot yourself in the foot by tying
> general unicode representation of an object to work only for HTML. I'd
> rather leave it to some special filter.
Probably. I'm definitely being lazy ;)
But the bug is still just as valid for any object which uses
__unicode__ to display it.
For example, you had a Form which you wanted to run through a filter
(for some reason)
{{ form|some_html_parser_filter }}
(sure, you can get around that too in this case by calling the method
which __unicode__ does but you get the idea, right?)
Maybe it's just a limitation which should be documented?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
On Thu, 2007-11-22 at 14:26 -0800, SmileyChris wrote:
> On Nov 22, 10:48 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > P.S. However I think you try to shoot yourself in the foot by tying
> > general unicode representation of an object to work only for HTML. I'd
> > rather leave it to some special filter.
>
> Probably. I'm definitely being lazy ;)
>
> But the bug is still just as valid for any object which uses
> __unicode__ to display it.
>
> For example, you had a Form which you wanted to run through a filter
> (for some reason)
> {{ form|some_html_parser_filter }}
> (sure, you can get around that too in this case by calling the method
> which __unicode__ does but you get the idea, right?)
>
> Maybe it's just a limitation which should be documented?
I've fixed it, after a fashion, in r6721.
Kind of annoying (the fix), because stringfilter was always kind of a
stupid decorator (it didn't save any lines of code), but now it has
genuine value as a way to handle this situation, so I can't hate it with
a passion any longer. So my whole universe has been slightly tilted
(even further).
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: is_safe problem
On Nov 29, 9:28 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I've fixed it, after a fashion, in r6721. Why no tests? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: is_safe problem
On Wed, 2007-11-28 at 15:06 -0800, SmileyChris wrote: > On Nov 29, 9:28 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > I've fixed it, after a fashion, in r6721. > > Why no tests? Drop them in a ticket and I'll commit them. Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: is_safe problem
On Nov 29, 12:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Drop them in a ticket and I'll commit them. http://code.djangoproject.com/ticket/6049 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
