Re: There should be a way to make Templates substitution to raise an exception on error

2017-09-27 Thread Sjoerd Job Postmus 
Also: inline.

On Wednesday, September 27, 2017 at 4:55:32 PM UTC+2, pandyas...@gmail.com 
wrote:
>
> Please find comment inline
>
> On Friday, 22 September 2017 15:44:38 UTC+5:30, Sjoerd Job Postmus wrote:
>>
>> Indeed it could be!
>>
>> What if it was not `string_if_invalid` but `if_invalid`. The value could 
>> be:
>>
>> * An Exception instance (which would then be raised)
>> * An Exception class (which would be instantiated with the "invalid" 
>> thing), and then be raised
>> * A callable (which would be called, and must return a string or raise), 
>> and the result used (unless it raises an exception, in which case that 
>> exception is propogated upwards)
>> * A string (which would be interpolated with `%` if it contains "%s") to 
>> be used instead.
>>
> This seems like an overkill. What if we instead provide an additional 
> boolean flag `raise_if_invalid`
>

I do agree that the above specification seems overkill. However, I think 
that a boolean flag `raise_if_invalid` is the wrong approach: One could 
have both `string_if_invalid` defined and `raise_if_invalid` (and will we 
also add `log_if_invalid`?).

For simplicity, having an `if_invalid` that is a callable that either 
returns a string (or raises an exception) seems to be the most generic 
approach. For Django it's "always call the function" (the default simply 
would be `return ''`). One can add all the logic one wants into that 
specific function: raising exceptions, logging, returning a string (like 
`string_if_invalid`?)

All the other options (Exception instances and classes and strings) are 
indeed overkill (it can be handled by that function I mentioned), but would 
allow for a simpler `settings.py`.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/75152154-6a86-4d4a-8513-faea06d556b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: There should be a way to make Templates substitution to raise an exception on error

2017-09-27 Thread pandyashreyas1 
Please find comment inline

On Friday, 22 September 2017 15:44:38 UTC+5:30, Sjoerd Job Postmus wrote:
>
> Indeed it could be!
>
> What if it was not `string_if_invalid` but `if_invalid`. The value could 
> be:
>
> * An Exception instance (which would then be raised)
> * An Exception class (which would be instantiated with the "invalid" 
> thing), and then be raised
> * A callable (which would be called, and must return a string or raise), 
> and the result used (unless it raises an exception, in which case that 
> exception is propogated upwards)
> * A string (which would be interpolated with `%` if it contains "%s") to 
> be used instead.
>
This seems like an overkill. What if we instead provide an additional 
boolean flag `raise_if_invalid`

>
> (in that order).
>
> We also use the `string_if_invalid` trick with a custom class that 
> provides `__mod__`/`__contains__`. Would be great if we could handle that 
> at the Django layer.
>
> On Friday, September 22, 2017 at 11:00:00 AM UTC+2, Adam Johnson wrote:
>>
>> I've used a solution like the one Emil links to before to great success, 
>> though perhaps there's scope to make it a bit less hacky in Django.
>>
>> On 22 September 2017 at 07:10, Emil Stenström  wrote:
>>
>>> It as actually possible, just in a very hacky way. Django has a setting 
>>> called TEMPLATE_STRING_IF_INVALID (or TEMPLATES[0]["OPTIONS"]["
>>> string_if_invalid"] in current versions of Django). If you override it 
>>> and set it to a class with a __str__ that raises an exception you can get 
>>> the effect you want. We use this in tests to find missing variables quickly.
>>>
>>> Reference code: https://djangosnippets.org/snippets/646/
>>>
>>> On Thursday, 21 September 2017 13:05:28 UTC+2, Shreyas Pandya wrote:

 Hi All,

 What is your opinion on having an option to raise an error in template 
 if variable is not found in context. This may be useful for automated 
  tests as discussed in ticket. 

 reference ticket #28618 
  ; 

 Thanks

 regards
 Shreyas

>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/02995ca2-2721-4526-89de-408bb3be642d%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Adam
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a194518-856a-4c6a-a6e2-7ee15d27f84c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Templates: __html__ method support

2017-09-27 Thread Patryk Zawadzki 
W dniu wtorek, 26 września 2017 14:34:29 UTC+2 użytkownik Jonas H napisał:
>
> Proposal: Support the __html__ method as an alternative/addition to the 
> __str__ for turning objects into strings in the template layer.
>
> If this has been discussed before, please point me to it; I couldn't find 
> anything with the search function.
>
> Some custom classes may have, in addition to a __str__ representation, a 
> natural representation that is better suited for HTML output.
>

Another proposal:

Introduce a single-dispatch html function (
https://docs.python.org/3/library/functools.html#functools.singledispatch).

Have the default implementation call param.__html__() if it exists and fall 
back to param.__str__().

Document using html.register(...) as the preferred extension method.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/429010b7-7606-4f57-b4ca-c449005dfa32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.