Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

   
   1. it's not necessarily about SSL, it can be for any protocol but SITE 
   dependent.
   2. and for the dev/prod , your data will be different anyway so you put 
   the preferred protocol accordingly to your setup.
   3. it's only for generating full URLs, not for internal links (ex: 
   sitemaps). 

a settings option could work too for sure, but I think we have more 
flexibility with the sites framework, and any time you need the protocol 
it's to generate a full URL which also needs the domain name.

-- 
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/2d0a6998-e21d-4a56-8380-2cf1273e3f97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

since no feedback has been given yet,   I will add that the change is just 
an addition (new feature)  meaning there is no breaking of code , it just 
provides a way to define a default protocol for a given SITE, and will 
ultimately default to http when none is specified

-- 
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/df5ea735-b41e-4197-96a8-2cb6333bf3de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

Hi

I've created a ticket to propose adding a preferred/default protocol in the 
"sites" framework at https://code.djangoproject.com/ticket/26079

tim suggested I bring this to the mailing list and said the following:

I'm not immediately convinced that a database field is the way to go for a 
> couple reasons:
>
>1. It would make data less portable between development (where SSL is 
>often not in use) and production.
>2. I'm not sure it's a common case that only some sites would use SSL 
>but not others.
>
> A third-party library called django-hosts, which djangoproject.com uses, 
> adds a setting called ​HOSTS_SCHEME 
> 
>  to 
> solve this. I think there's been some discussion about merging at least 
> parts of this library into core since it solves common problems.
>
> See also #10944  (we might 
> close this ticket as a duplicate of that one) and #23829 
>  (about customizing 
> ping_google to allow https). I think the best course of action would be 
> to consider this feedback and write to the DevelopersMailingList 
>  with your 
> proposal. Either solution of a new setting or a new database field need 
> feedback from a wider audience. Thanks!
>

   - actually I would say it is even more portable as you 
   would probably use different databases between dev and prod , meaning you 
   can have http in dev but https in prod
   - its not just for SSL but also maybe a it could be used with other 
   protocols/schemes such as dav, webcal, feed
   - third party libraries could now have a definitive way of generating a 
   full URL 

what do you guys think?

-- 
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/4daa6fb3-071a-4ca0-849c-63283cc3737b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Eric Rouleau]

+1 for me too

On Thursday, March 6, 2014 3:28:59 PM UTC-5, Andre Terra wrote:
>
> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  > wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini 
>> > > wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they 
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail 
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is 
>>> presentational log and belongs in templates (<- unless I'm wrong about 
>>> that, please suggest a refactoring to me if you believe one is appropriate 
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning 
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release 
> of nuclear material.  While building the application, my grandfather put 
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some 
> reason it never detected that it was safe to release the deadly fissile 
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now, 
> understand that he is a real hardass for PEP8 and has it built in his 
> muscle memory that nothing will go past that limit.  Unfortunately, my 
> extra statement just happened to go right over the 80 character limit 
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of 
> deadly, central nervous system destroying radiation we had built up in 
> the 
> reactor (that stuff tends to clog up the pipes).  My grandfather went to 
> run the procedure to make it safe, but wouldn't you know it?  That debug 
> statement was still there.  Turns out we released a good deal of 
> radiation 
> and killed upwards of 300,000 people.  They had to evacuate the city and 
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off 
> that he has to scroll past the 80 character column to fix the issue.
>
  
 As amusing as your story is, hyperbole won't win the argument.  

 Hyperbole aside, you haven't added anything to the discussion that we 
 didn't already know. Yes, long logic lines can lead to clauses being 
 hidden 
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't 
 do that. One of the reasons that Django's template logic is intentionally 
 hobbled is that we want to discourage putting business logic in the 
 template. Not adding multiline tags is one of the contributors to this 
 hobbling. Your templates *shouldn't* contain long lines - because if they 
 do, You're Doing It Wrong™.

 How should it be done? Depending on circumstances, you could refactor 
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag setting a local value in the context

 {% show_form_state as ok_to_show_form %}
  {% if ok_to_show_form %}

 All of these come in at *much* less than 80 characters, and better 
 still, they all force you to put the "display the form" logic somewhere 
 that it can be tested and validated, so no only will your grandfather be 
 able to read his template unambiguously, but he'll be able to write formal 
 tests to ensure that humanity isn't doomed to a future of extra limbs and 
 superpowers.

 Which one of these