Re: include_block template tag

[Sam Willis]

Hi Carlton, 

Thanks for chipping in.

As a long time user of Django (I first stated with it back in 2006) from my 
experience where is excels is in providing a full toolbox for building 
things for the web. The most successful “third party” apps and library’s 
tend to be very large editions of functionality rather than small functions 
and template tags. I personally stay away from small libraries as I have 
been bitten before when they are no longer maintained.

One of the criticisms of Node.js and from personal experience reasons why 
people prefer Django and similar “everything included” frameworks is the 
fragmentation of tools and large number of dependancies.

For this reason I don’t think there will ever be a successful “third party” 
implementation of this particular idea. It’s not a big enough tool for 
people to justify adding to their dependancies. (People are more likely to 
swap to Jinja which has Macros and are “sort of” similar if you squint at 
them)

Also, last year I had a quick look at my old implementation again and I 
think I came to the conclusion that it would require some small changes to 
core in order to work. I don’t remember what they are now though.

I understand completely that the barrier for adding new functionality to 
Django should be high. It important to maintain its “maintainability” and 
stop feature creep, but I also think that there is a risk of not developing 
new ideas and attracting new developers and users if it is only 
“maintained”.

(Obviously there are new things happing like the incredible and exciting 
work going into async!)

Anyway, to summarise, I think this needs to be in core to get traction and 
for people to discover it. For some ideas going the external route to prove 
it certainly makes sense but for others (like this) I think it should be 
developed though consensus in the core framework.

Reusable template components are still an unsolved problem that would be 
lovely to solve.
Thanks!
Sam
On Wednesday, August 19, 2020 at 1:05:15 PM UTC+1 jure.er...@gmail.com 
wrote:

> It definitely does. Thanks.
>
> Jure
>
> On 19/08/2020 14:03, Carlton Gibson wrote:
> > From the thread, I’d suggest collaboration with Curtis if the ideas are 
> similar enough.
> >
> > Also from the thread: the idea seems to fit between include as we have 
> it now, and a custom tag.
> > Maybe that gap hasn’t been wide enough to grasp sufficient interest?
> >
> > I think the standard path for inclusion into core goes more or less:
> >
> > * Here’s an idea
> > * Here’s a third-party implementation.
> > * Everyone[*] is using it, and the troubles have been ironed-out
> > * let’s merge it.
> >
> > [*]: Everyone ≈ a good number.
> >
> > For a third-party lib, there’s no need for it ever get to the last step. 
> (It could but it doesn’t have to.)
> > Everything we can keep somewhere else makes Django more maintainable, so 
> there’s a general preference for NOT including things if possible.
> >
> > Hopefully that makes sense.
> >
> > Kind Regards,
> >
> > Carlton
> >
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com.

Re: include_block template tag

[Sam Willis]

Hi Jure,

I think this would be a great addition to Django!

I also proposed something a few years ago which was almost identical 
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ) 
and had a basic implementation (it probably won't work anymore without some 
tweaks). However from my experience then it will be difficult to get this 
into core without the championing from a core developer.

If there was enough interest I would certainly be happy to contribute to 
the feature!

Sam

On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote:
>
> While rendering templates we often come into situations where data remains 
> the same, but sometimes we want to render it one way, other times - another.
>
> Examples:
>
> a library supporting various CSS frameworks. You would always render panel 
>  title and 
> panel body, but bootstrap does it using one HTML, material uses another.
>
> you may decide to render a piece of data in a panel, input, table cell, 
> etc.
>
> analysis:
>
> There's a huge note with include tag 
>  
> clarifying how include tag is NOT used for purposes listed above. This 
> leads me to believe (but I have not researched it thoroughly) that the 
> question has been asked many times before.
>
> proposal:
>
> implement support for passing HTML renders into an included template.
>
> I see two possible approaches for this:
>
> Approach 1 template example:
>
> {% includeblock template with ... %}
> {% subblock block1 %}
>  HTML code
> {% endsubblock %}
> {% subblock block2 %}
>  HTML code
> {% endsubblock %}
> {% endincludeblock %}
>
> block1 and block2 would be blocks defined in template using existing block 
> syntax. I'm not sure if recycling existing block tag would be possible in 
> this context, but I would certainly prefer to avoid new template tag 
> syntax. Basically what this tag would do is first evaluate the subblocks, 
> then override the blocks defined in the template, then render the template.
>
> Approach 2 template example:
>
> {% block block1 as block1_var %}
>HTML code
> {% endblock %}
> {% subblock block2 %}
>HTML code
> {% endsubblock %}
> {% include template with block1=block1_var block2=block2_var %}
>
> This approach is a bit less structured than the first one, but it requires 
> a lot less modification. Basically it would only add the with parameter to 
> store block render in a variable instead of actually rendering it to 
> output. Possible problem with block inheritance within the template.
>
>
> Would either of the above be interesting to include in Django templating 
> code?
>
> Thanks for your consideration,
> Jure
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com.

Re: Deprecating logout via GET

[Sam Willis]

Why not have the logout link take the user to a page asking them to confirm the 
logout, and have it as a POSTed form button from there?

That adds a helpful confirmation page, removes the difficulties of styling a 
button as a link constantly (or changing the header design to a button).

One downside would be the change in behaviour, people will be used to the 
logout link immediately logging them out and so may not read the next page...

I’m sure there is literature in best practices for logout confirmation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%40googlegroups.com.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Sam Willis]

Hi,

It looks to me like this has introduced a slight behaviour difference with 
1.11 on python 2.7 than on 3.x:

https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36

The release notes don't indicate what the difference in behaviour is 
between python 2 and 3.

I'm trying to follow the change and test cases but it looks like if you 
have two users 'm...@example.org' and 'mık...@example.org' (which is highly 
unlikely anyway to happen legitimately) neither can reset their password 
anymore on py2?

See: 
 
https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
 

I'm guessing this was found after the similar GitHub vulnerability was 
found?

Thanks for the hard work!

On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak wrote:
>
> Details are available on the Django project weblog: 
>
> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.com.

Re: Align Django admin checkboxes

[Sam Willis]

I believe this is designed so that when there are multiple checkboxes in a 
line they look like this:





On Monday, August 28, 2017 at 9:41:05 PM UTC+1, Collin Anderson wrote:
>
> A hybrid approach could be better. (To create this mockup I inserted an 
> empty "label" tag.)
>
> [image: Inline image 1]
>
> On Mon, Aug 28, 2017 at 4:24 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> At first sight, the checkbox and the label is clickable in the first 
>> example while only the checkbox is in the second example. That's a 
>> regression in usability.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 28 Aug 2017, at 11:38, Zach > wrote:
>>
>> Hi. Currently the alignment of the checkboxes are inconsistent with other 
>> form fields. It makes sense to align the checkbox and create a consistent 
>> user experience.
>>
>>
>>
>> 
>>
>> -- 
>> 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/b57f87df-d622-42d9-8414-21e488a85336%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> -- 
>> 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/9D88058C-81A1-4704-A3FB-A508FDEDE130%40polytechnique.org
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/cca2864f-9b2f-4f15-922d-b5975ad022e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Subresource Integrity

[Sam Willis]

Hi,

You may have come across the (relatively) new subresource integrity 
(SRI)[1] security feature that is available in Chrome and Firefox (its 
coming to Edge[2] and Safari[3]) - it enables a hash to be provided as an 
attribute on a linked JavaScript or CSS tag that the browser can test 
against once the file has downloaded to ensure that it hasn't been tampered 
with. Its main use case is for when you are using a third party CDN for 
your static files. I have been looking at how best to implement it in/with 
Django and believe that incorporating it into the 'staticfiles' framework 
may be the best we to go.

Currently 'ManifestStaticFilesStorage' and 'CachedStaticFilesStorage' store 
a simple dict mapping file path to path was a hash in the filename for 
cache busting. I would like to propose that this is changed to a mapping of 
file path to a tuple of (filepath_with_hash, hash_algo, file_hash_base64). 
This allows us to add the subresource integrity attribute to any linked 
file that is managed by either of those storages.

I have mocked up how this could be done [4], the changes I made 
to django/contrib/staticfiles/storage.py are here [5].

There is then a simple template tag that includes the SRI token:
{% static_sri_token 'path/to/file.js' %}
>>> sha256-ATJWBF9ZhO9FS8vr9wEhYO+W9vLtd3jRZVmEdC5EL0s=

or the whole attribute:
{% static_sri_attrs 'path/to/file.js' %}
>>> integrity="sha256-ATJWBF9ZhO9FS8vr9wEhYO+W9vLtd3jRZVmEdC5EL0s=" 
crossorigin="anonymous"

By incorporating this into Django rather than a third party app it would 
ensure that everyone gains access to this new security feature for free - 
it can be documented with the static files docs, encouraging its use and 
help to secure more peoples projects.

Please note that my code is just a proof of principle, and I would be very 
happy to hear if anyone has any thought on a better way of implementing the 
feature.

[1]: 
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[2]: 
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/subresourceintegrity/
[3]: https://webkit.org/status/#feature-subresource-integrity
[4]: https://gist.github.com/samwillis/90b5391f9dafc0662ae2af7b8f827bd9
[5]: 
https://gist.github.com/samwillis/90b5391f9dafc0662ae2af7b8f827bd9/revisions#diff-80f99275da9c9dbb59bb177e83b9f13e

-- 
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/26ac849d-d6d1-4e9e-aa14-d16b0552a43f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing and renaming Django's Python 2 related helpers

[Sam Willis]

Hi,

An alternative option with 'six' is to replace it with an alias of six 
propper (not vendored), something like this:

# django/utils/six.py
try:
from six import *
except ImportError:
raise ImportError((
"`django.utils.six` is deprecated, install six from pypi "
"(https://pypi.python.org/pypi/six) instead. After installing 
it will be available at "
"`django.utils.six` until Django V2.xx."))
except:
import warnings
warnings.warn((
"The `django.utils.six` alias is deprecated and will be removed 
in Django V2.xx.",
DeprecationWarning, 2
)

That way it removes the need for it to be maintained in core but ensures 
that other Django apps that are supporting py2 and 3 don't break.

Sam

On Tuesday, January 24, 2017 at 11:53:01 AM UTC, Aymeric Augustin wrote:
>
> Hello,
>
> Django is earning a lot of goodwill from its well-defined deprecation 
> policy. It was recently improved to allow pluggable apps to work without 
> import shims and without deprecation warnings from one LTS to the next. I 
> don’t know the exact details but I believe that's the intent.
>
> Combined with a thorough documentation of backwards-incompatible changes, 
> it helps many developers put up with changes, even those they don’t 
> understand, disagree with, or require significant work to adapt 
> applications.
>
> For this reason, in the context of the transition from Python 2 to Python 
> 3, which is very backwards incompatible for people who haven’t been able to 
> anticipate it, I’m in favor of a generous application of the deprecation 
> policy.
>
> I’m +1 on deprecating rather than removing utilities that were mentioned 
> in the documentation, notably python_2_unicode_compatible, which was a 
> public API until it got merged into six and we started using six’ version.
>
> I’m +0 on deprecating rather than removing modules that a developer of a 
> pluggable app would reasonably use for Python 2 compatibility, such 
> as django.utils.lru_cache or django.utils.six.
>
> I’d just remove less visible functions such as django.utils._os.abspathu, 
> provided they clearly fall in the “private API” bucket.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 21 Jan 2017, at 21:55, Tim Graham > 
> wrote:
>
> As we worked on removing Python 2 compatibility code from master this week 
> [0], we collected a number of import shims and functions that are only 
> needed for code that wants to support Python 2 [1].
>
> So far there is django.utils.six, as well as some undocumented things:
>
>- django.utils.lru_cache 
>- django.utils._os.abspathu, upath, npath 
>- django.utils.decorators.available_attrs
>- django.utils.encoding.python_2_unicode_compatible
>
> I'm advocating to remove the undocumented things in Django 3.0 (released 
> Dec. 2019) or later without a deprecation. By that time, I hope third-party 
> apps won't support Python 2 either and so part of adding Django 3.0 
> compatibility will include formally dropping support for Python 2 (if not 
> done already) and removing usage of this stuff (a fairly easy find/replace, 
> hopefully).
>
> Others have advocated to deprecate all these things, but I don't see much 
> advantage. If I were maintaining an app, I'd rather be able to use import 
> shims without warnings until Python 2 is gone. What's your preference?
>
> A similar concern applies to django.utils.http's urlquote() and 
> urlquote_plus() (documented) and urlunquote() and urlunquote_plus() 
> (undocumented). Claude has a PR that deprecates them [4] which I think is 
> fine considering they are half documented.
>
> A related issue is the naming of the force_text() / force_str() and 
> smart_text() / smart_str() functions. Aymeric proposed a PR to change all 
> force_text() 
> usage in Django to force_str() (they function identically on Python 3) [2], 
> however, I feel this might create some confusion. For example, when 
> backporting to 1.11 and earlier, we'll have to change force_str() to 
> force_text() for Python 2 compatibility. Third-party apps might also be 
> confused on which function to use. Claude proposed a similar that changes 
> ugettext() 
> and ungettext() to gettext() / ngettext() [3]. Would it be less confusing 
> to consider these changes when Python 2 is no longer supported by any 
> version of Django?
>
> [0] https://code.djangoproject.com/ticket/23919
> [1] https://code.djangoproject.com/ticket/27753
> [2] https://github.com/django/django/pull/7913
> [3] https://github.com/django/django/pull/7916
>
> -- 
> 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 v

Re: Add custom autoreload file tracking options setting

[Sam Willis]

Could one options be to replace the current devserver with the one from 
Werkzeug? It already uses watchdog (similar to watchman) for monitoring 
file system events and is well maintained. With Django now allowing 
dependancies, this seems like something that doesn't necessarily need to be 
developed internally.

The Werkzeug devserver also has some niceties like an interactive debugger 
and ssl hosting with an automatically issued self signed certificate. It 
could be implemented behind the current management command relatively 
easily.

There is already an implementation as part of django-extentions that I 
believe is well used and battle tested 
- http://django-extensions.readthedocs.io/en/latest/runserver_plus.html 


On Thursday, January 5, 2017 at 9:11:53 AM UTC, Aymeric Augustin wrote:
>
> On 4 Jan 2017, at 23:31, Bobby Mozumder > 
> wrote: 
>
> > I guess I could just use Watchman to restart the Django development 
> server as needed? 
>
>
> If you find a way to tell watchman to run `django-admin runserver 
> --noreload` and restart it whenever a file in the current directory 
> changes, that should do the job. 
>
> Unfortunately the APIs exposed by watchman don’t make this trivial. 
> They’re intended to run a build process that will terminate, while the 
> development server will keep running. 
>
> -- 
> Aymeric. 
>
>

-- 
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/6d346a13-b096-42f8-a15b-a2814a81eef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing {% include %} to strip a trailing newline

[Sam Willis]

Could this be set within the template rather than the include tag? So for 
example have a new tag such as {% strip_final_new_line %} that when 
included at the end of a template immediately before the final new line 
would instruct it to be striped.

This stops the user from having to remember to use a special option on the 
include tag for each use of a template that requires it - it also work on a 
normal (not included) template render as well, if that is wanted.

An alternative tag could be {% endtemplate %} that can be placed anywhere 
in the template, forcing the end of rendering?

On Wednesday, January 4, 2017 at 7:58:42 PM UTC, Tim Graham wrote:
>
> Shortly after template widget rendering was merged, an issue about extra 
> newlines appearing in the rendered output was reported [0]:
>
> For example, from django-money:
>
> UIC-Franc
> \n\n
> US Dollar
> \n\n
>
> The newlines aren't useful and they break assertions like this:
>
> US Dollar in form.as_p
>
> --- end report---
>
> The reporter suggested removing the trailing newline in the attrs.html 
> template but Adam Johnson reported: "POSIX states that all text files 
> should end with a newline, and some tools break when operating on text 
> files missing the final newline. That's why git has the warning \ No 
> newline at end of file and Github has a warning symbol for the missing 
> newline."
>
> I suggested that perhaps {% include %} could do .rstrip('\n') on whatever 
> it renders.
>
> Preston pointed out that Jinja2 does something similar:
>
> http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
>
>- a single trailing newline is stripped if present
>- other whitespace (spaces, tabs, newlines etc.) is returned unchanged
>
> I noted that the issue of {% include %} adding extra newlines was raised 
> in #9198 [1] but Malcolm said, "For backwards compatibility reasons we 
> cannot change the default behaviour now (there will be templates that rely 
> on the newline being inserted)." I was skeptical this would be a burdensome 
> change.
>
> Carl replied:  "It seems quite likely to me that there are templates in 
> the wild relying on preservation of the final newline. People render 
> preformatted text (e.g. text emails) using DTL. I probably have some text 
> email templates in older projects myself that would break with that change. 
>
> We could add a new option to {% include %}, though." Adam also said, "I 
> too have used DTL for text emails that would break under that behaviour. 
> New option to include sounds good to me."
>
>
> Me again: In the long run, having {% include %} remove the trailing 
> newline seems like a more sensible default. For example, I wouldn't expect 
> this code to have a newline inserted between it:
>
>
> {% include "foo.txt" %}
> {% include "bar.txt" %}
>  
>
> An option for {% include %} seems superfluous given that if you were 
> writing
>
>
> {% include "foo.txt" %}{% include "bar.txt" %}
>  
>
> now you can write the first thing which is much more intuitive.
>
>
> How about a keep_trailing_newline TEMPLATES option for backwards 
> compatibility for those who don't want to adapt their templates for the new 
> behavior? Jinja2 has that option.
>
> Carl replied: An engine option may be better than an option to {% include 
> %}, though it doesn't allow us to ensure that we strip the newline in the 
> specific case of attrs.
>
> How we default the engine option I guess just depends on how seriously we 
> take backwards compatibility. If we default it to strip and make people add 
> the config to preserve the old behavior, that's not really backwards 
> compatible. Historically (as seen in Malcolm's comment) we would choose to 
> err on the side of actual backwards compatibility in a case like this, even 
> if it didn't result in the ideal future behavior. But the adaptation isn't 
> hard in this case, so I won't object if the choice is to break back-compat.
>
>
> If it's not a per-include choice, of course, we have to break overall 
> back-compat to preserve form-attr-rendering back-compat.
> 
>
> What do you think?
>
> [0] https://github.com/django/django/pull/7769
> [1] https://code.djangoproject.com/ticket/9198
>

-- 
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/1819d705-7b6a-46f0-9ede-dee3cf5d7b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Sam Willis]

As far as I can tell the only place where Django's Python 2.x deprecation is 
stated is here https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

I think it should be more prominently stated in the docs, and as 1.11 is 
supposedly the last to support 2.7 (according to the blog post) it may be worth 
promoting it as such.

Maybe there should be a pominant announcement about which version is the last 
to support 2.7? Maybe in the release notes of 1.10?

-- 
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/678cee6c-3df4-4715-b6af-3d20bf3f3822%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels integration plan, first draft

[Sam Willis]

Hi,

To support file uploads or a large message body the http.request message 
could have an file_channel or body_channel (much like its reply_channel)? 
These would be something like http.request.file.Dj3Hd9J and would stream 
chunked file or body content in the same way as the http.response message 
with a more_content attribute.

Sam

On Thursday, December 17, 2015 at 9:48:31 PM UTC, Andrew Godwin wrote:
>
> Yes, that is the idea. While it obviously adds overhead (a millisecond or 
> two in my first tests), it also adds natural load balancing between workers 
> and then lets us have the same architecture for websockets and normal HTTP.
>
> (The interface server does do all the HTTP parsing, so what gets sent over 
> is slightly less verbose than normal HTTP and needs less work to use, but 
> it's not a big saving)
>
> Andrew
>
> On Thu, Dec 17, 2015 at 9:01 PM, Anssi Kääriäinen  > wrote:
>
>> Is the idea a large site using classic request-response architecture 
>> would get the requests at interface servers, these would then push the HTTP 
>> requests through channels to worker processes, which process the message 
>> and push the response through the channel backend back to the interface 
>> server and from there back to the client?
>>
>>  - Anssi
>>
>> On Thursday, December 17, 2015, Andrew Godwin > > wrote:
>>
>>> To address the points so far:
>>>
>>>  - I'm not yet sure whether "traditional" WSGI mode would actually run 
>>> through the in memory backend or just be plugged in directly to the 
>>> existing code path; it really depends on how much code would need to be 
>>> moved around in either case. I'm pretty keen on keeping a raw-WSGI path 
>>> around for performance/compatability reasons, and so we can hard fail if 
>>> you try *any* channels use (right now the failure mode for trying to use 
>>> channels with the wsgi emulation is silent failure)
>>>
>>> - Streaming HTTP responses are already in the channels spec as chunked 
>>> messages; you just keep sending response-style messages with a flag saying 
>>> "there's more".
>>>
>>> - File uploads are more difficult, due to the nature of the worker model 
>>> (you can't guarantee all the messages will go to the same worker). My 
>>> current plan here is to revise the message spec to allow infinite size 
>>> messages and make the channel backend handle chunking in the best way 
>>> (write to shared disk, use lots of keys, etc), but if there are other 
>>> suggestions I'm open. This would also let people return large http 
>>> responses without having to worry about size limits.
>>>
>>> - Alternative serialisation formats will be looked into; it's up to the 
>>> channel backend what to use, I just chose JSON as our previous research 
>>> into this at work showed that it was actually the fastest overall due to 
>>> the fact it has a pure C implementation, but that's a year or two old. 
>>> Whatever is chosen needs large support and forwards compatability, however. 
>>> The message format is deliberately specified as JSON-capable structures 
>>> (dicts, lists, strings) as it's assumed any serialisation format can handle 
>>> this, and so it can be portable across backends.
>>>
>>> - I thought SCRIPT_NAME was basically unused by anyone these days, but 
>>> hey, happy to be proved wrong. Do we have any usage numbers on it to know 
>>> if we'd need it for a new standalone server to implement? It's really not 
>>> hard to add it into the request format, just thought it was one of those 
>>> CGI remnants we might finally be able to kill.
>>>
>>> Andrew
>>>
>>> On Thu, Dec 17, 2015 at 6:32 PM, Anssi Kääriäinen  
>>> wrote:
>>>
 On Thursday, December 17, 2015, Carl Meyer  wrote:

> Hi Andrew,


> - I share Mark's concern about the performance (latency, specifically)
> implications for projects that want to keep deploying old-style, given
> all the new serialization that would now be in the request path. I 
> think
> some further discussion of this, with real benchmark numbers to refer
> to, is a prerequisite to considering Channels as a candidate for Django
> 1.10. To take a parallel from Python, Guido has always said that he
> won't consider removing the GIL unless it can be done without 
> penalizing
> single-threaded code. If you think a different approach makes sense 
> here
> (that is, that it's OK to penalize the simple cases in order to
> facilitate the less-simple ones), can you explain your reasons for that
> position?
>

 We would also need some form of streamed messages for streamed http 
 responses.

 Is it possible to handle old-style http the way it has always been 
 handled?

  - Anssi 

 -- 
 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 

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi Jonathan,

I agree it may be one step to far but I thought it may be worth discussing 
as it opens up an interesting option for overcoming some of the 
shortcomings of the current 'include' tag. It actually isn't to hard to 
implement, I think my code should be pretty close to what would end up in 
use if it is accepted. The alternative to the namespaces could be adding a 
'public' option to the tag that makes the blocks inside available to 
overwrite?

 I am particularly keen on being able to override multiple blocks, I think 
this is a good example of what could be constructed with this tag. 
Bootstrap has a Modal component and the code below uses its markup as an 
example::

# modal.html

  

  {% if used_block.header %}

  ×Close
  {% block title 
%}{% endblock %}

  {% endif %}
  {% if used_block.body %}

  {% block body %}{% endblock %}

  {% endif %}
  {% if used_block.footer %}

  {% block footer %}{% endblock %}

  {% endif %}

  


This could then be included in a page in the following ways:

# my_page.html

{% use 'modal.html' with modal_id='settings_modal' %}
  {% block title %}
Your Settings
  {% endblock %}
  {% block body %}
... A settings form? ...
  {% endblock %}
  {% block footer %}
Close

Save changes
  {% endblock %}
{% enduse %}


{% use 'modal.html' with extra_class='large' modal_id='annother_modal' %}
  {% block title %}
Another Modal
  {% endblock %}
  {% block body %}
This one has no footer/
  {% endblock %}
{% enduse %}


{% use 'modal.html' with extra_class='small' block body %}
  This one doesn't even have a title, and as we are just overriding a 
single block we loose the block tags.
{% enduse %}

In the template we are using the 'used_blocks' context variable to decide 
when to include the div's that wrap the head, body and footer of the modal. 
We are also using the extra context variables assigned by the use tag to 
choose if its a normal, large or small modal and give it an id.

This can obviously already be implemented with a hierarchy of extended 
templates but I think this tag creates a very clean way of structuring 
these components that doesn't require making custom template tags or lots 
of template files.


Sam




On Friday, September 5, 2014 2:55:28 PM UTC+1, Jonathan Slenders wrote:
>
> There I think you are going one step too far.
>
> I think people should not be able to override blocks inside an included 
> template in a "use"-block. That's one level too deep. It's confusing and 
> you have other solutions for that.
> In the template that you "use", you could put a {% block %} around the {% 
> include %} if you want to be able to replace that. It's a little more work, 
> but in my opinion, it's not worth introducing the concept of name spaces.
>
>
>
> Aside from that, there's one example that I would like to share, why we 
> would need something like this.
> Ofter we end up writing code like this:
>
> {% include "start_table.html" %}
> {% include "content.html" %}
> {% endclude "end_table.html" %}
>
>
> "start_table.html" would contain:
> .."
>
> "end_table.html" would contain:
> 
>
> Now open any of the "start/end_table.html" files in an editor, and the 
> editor will not be able to find the matching tags.
> On the other hand, if you can have:
>
> {% use "table.html" %}
> {% include "content.html" %}
> {% enduse %}
>
>
> Then we have the HTLM open and close tags in the same file.
> (I agree that in this specific example, there is an alternative: use 
> extends in the included template. But there are many cases where you don't 
> want that, because you need e.g. the decorated and non-decorated version of 
> the include.)
>
> Now, whether or not to allow overriding multiple blocks of the "used" 
> template. I don't know. It's technically also possible to support both 
> cases. (E.g. replace the content of the "content" block if no blocks are 
> defined between "use" and "enduse". Otherwise, find matching block namess, 
> like with {% extends %}.)
>
>
>
>
>
> Le jeudi 4 septembre 2014 19:11:57 UTC+2, Sam Willis a écrit :
>>
>> Hi again,
>>
>> One thing that I wasn't happy with in the implementation I posted 
>> yesterday was that you could not override templates included using 'use' in 
>> another child template. Effectively all blocks inside the 'use' tag and its 
>> included template where 

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi again,

One thing that I wasn't happy with in the implementation I posted yesterday 
was that you could not override templates included using 'use' in another 
child template. Effectively all blocks inside the 'use' tag and its 
included template where invisible outside of it. This needed to be the case 
so that you didn't get block names clashing with each other and could use 
the 'use' tag to include the same template with the same blocks overridden 
multiple times in one template

One potential solution to this is to enable blocks to have namespaces, so 
for example if you had the template:

# page_heading.html

{% block heading %}My Heading{% endblock %}
{% block sub_heading %}My Subheading{% endblock %}


and included it a template such as (note the 'ns page_heading'):

# base_page.html
...
{% use 'page_heading.html' ns page_heading %}
{% block heading %}Basic Page Heading{% endblock %}
{% enduse %}
...

You could then override the 'heading' block in a child template of 
'base_page.html' by doing:

# actual_page.html
{% extends 'base_page.html' %}
{% block page_heading.heading %}Basic Page Heading{% endblock %}

I have updated my implementation to support this here: 
https://gist.github.com/samwillis/af3992f69c2597a16252

It requires that the BlockContext supports namespaces, in my implementation 
there is NsBlockContext which is patched in when required but if this was 
accepted into core then NsBlockContext would replace BlockContext.

This is (almost) fully backwards compatible with existing code as blocks 
already named with periods will just end up in a namespace but continue to 
function fully. The only exception is if you have blocks named both 
'global.block_name' and 'block_name' as these would now address the same 
block. We could give the global namespace a more obscure name (such as 
'__global__') to prevent this but it would make the trick below more clunky.

One interesting use for the 'use' tag with this addition is breaking up 
more complex templates into multiple files. While researching various 
options before developing this I found allot of people discovering that you 
couldn't override a block inside an 'include'ed template. With this 'use' 
tag you would be able to do this, for example you could have base templates 
like this:

# base.html


{% use 'head.html' ns global %}{% enduse %}


 ...



# head.html
{% block title %}{% endblock %}

and the page template:

# actual_page.html
{% extends 'base.html' %}
{% block title %}My Page Title{% endblock %}

If we switched the 'use' tag to use a namespace other than global:

{% use 'head.html' ns html_head %}{% enduse %}

The page template would then be:

# actual_page.html
{% extends 'base.html' %}
{% block html_head.title %}My Page Title{% endblock %}

I think this will provide very useful in structuring complex templates.

Maybe with this functionality the tag should be called 'embed'?

What do you think?


Sam


On Thursday, September 4, 2014 5:28:34 PM UTC+1, Sam Willis wrote:
>
> Curtis,
>
> You are welcome to include it in your project and I'm happy to help out. 
> Depending on what happens here I may still release it as a simple 
> standalone app though.
>
> I do think this is the kind of thing that would do best in core though as 
> it would ensure that there was a standardised patten for creating these 
> reusable template components.
>
>
> Marc,
>
> I am happy to have a look around (and have already to some extent when 
> developing this) and put together a review of the various existing options. 
> This is my first foray into contributing to Django and so I am keep to help 
> in any way.
>
> Does anyone know of anything particular I should be looking at?
>
>
>
> On Thursday, September 4, 2014 2:06:15 PM UTC+1, Marc Tamlyn wrote:
>>
>> I would like to see someone do a review of the various third party 
>> implementations of concepts like this, I think there's a place in core for 
>> some variant, it's just working out which one the "right" one is.
>>
>> The other issue with adding new tags to core (especially with "common" 
>> names) is name clashes with third party code. This shouldn't be too 
>> significant though if we have enough use.
>>
>>
>> On 4 September 2014 12:09, Josh Smeaton  wrote:
>>
>>> I really like this idea, and have wanted something similar every time I 
>>> start a new project and begin building out the main template. I think 
>>> including this (or something like this) in core is a great idea. Just 
>>> because it *can* be implemented in 3rd party code, d

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Curtis,

You are welcome to include it in your project and I'm happy to help out. 
Depending on what happens here I may still release it as a simple 
standalone app though.

I do think this is the kind of thing that would do best in core though as 
it would ensure that there was a standardised patten for creating these 
reusable template components.


Marc,

I am happy to have a look around (and have already to some extent when 
developing this) and put together a review of the various existing options. 
This is my first foray into contributing to Django and so I am keep to help 
in any way.

Does anyone know of anything particular I should be looking at?



On Thursday, September 4, 2014 2:06:15 PM UTC+1, Marc Tamlyn wrote:
>
> I would like to see someone do a review of the various third party 
> implementations of concepts like this, I think there's a place in core for 
> some variant, it's just working out which one the "right" one is.
>
> The other issue with adding new tags to core (especially with "common" 
> names) is name clashes with third party code. This shouldn't be too 
> significant though if we have enough use.
>
>
> On 4 September 2014 12:09, Josh Smeaton 
> > wrote:
>
>> I really like this idea, and have wanted something similar every time I 
>> start a new project and begin building out the main template. I think 
>> including this (or something like this) in core is a great idea. Just 
>> because it *can* be implemented in 3rd party code, doesn't mean it has to 
>> be.
>>
>>
>> On Thursday, 4 September 2014 02:10:33 UTC+10, Sam Willis wrote:
>>>
>>>  Hi All,
>>>
>>> I would like to propose a new template tag to be included in Django, it 
>>> is sort of a cross between 'include' and 'extends'. You can find an 
>>> implementation here: https://gist.github.com/
>>> samwillis/af3992f69c2597a16252
>>>
>>> The main use case for this tag is being able to create reusable 
>>> 'components' for rendering a website. Say for example a page header, a 
>>> panel with headers and footers, or a modal window (as seen in the Bootstrap 
>>> framework). Rather than needing to repeat the html everywhere you need it 
>>> and having to search out all occurrences to make a change to the structure 
>>> you can create a simple template and include it.
>>>
>>> To some extent this can currently be done with either an included 
>>> template using the '{% include "template.html" with var="value" %}' syntax 
>>> or using a custom template tag. However, the former isn't suitable for 
>>> changing whole blocks in the include template, and the latter can be 
>>> overkill and may not be suitable for a designer with little knowledge of 
>>> Python and the Django Template API.
>>>
>>> The 'use' tag loads a template and renders it with the current context 
>>> similar to the 'include' tag. You can pass additional context using keyword 
>>> arguments as well as override blocks in the included template.
>>>
>>> Example (simple) template:
>>>
>>> 
>>> {% block heading %}{% endblock %}
>>> 
>>>
>>> Example 'use' tag use with the above template:
>>>
>>> {% use "page_header.html" %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> {% use "page_header.html" with extra_class="large" %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> As with 'include' use the 'only' argument to exclude the current context 
>>> when rendering the included template:
>>>
>>> {% use "page_header.html" only %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> {% use "page_header.html" with extra_class="large" only %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> The included template receives an additional context variable called 
>>> 'used_blocks' which is a Dict indicating which blocks were overridden in 
>>> the 'use' tag. Using this you can conditionally show content around the 
>>> block. For example, if you had this template for generating a page heading:
>>>
>>> 
>>> {% block heading %}{% endblock %}
>>> {% if used_blocks.sub_heading %}
>>>

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

If this was to be an addition to 'include' it would result in it having an 
optional closing tag, that seems a little confusing and you would need an 
argument to flag that there are blocks to override (and parse until the 
'endinclude').

The advantage over Jonathans 'decorate' tag is that you can override any 
and multiple blocks in the included template.



On Wednesday, September 3, 2014 5:46:24 PM UTC+1, Jonathan Slenders wrote:
>
> From 2011: 
> https://github.com/vikingco/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py
>
> My proposal was refused back then, but I'll be very happy if something 
> similar would make it. :)
>
>
>
> Le mercredi 3 septembre 2014 18:42:44 UTC+2, Jonathan Slenders a écrit :
>>
>> It's not similar. This implements the "decorator" pattern. Something that 
>> I've been proposing years ago.
>>
>>
>>
>> Le mercredi 3 septembre 2014 18:24:17 UTC+2, Ian a écrit :
>>>
>>> On Wed, Sep 3, 2014 at 10:10 AM, Sam Willis  wrote: 
>>> > Although I have implemented this with the 'use' word, there may be a 
>>> better 
>>> > word. I considered 'embed' but thought 'use' was a little cleaner 
>>>
>>> Since it's so similar to 'include', is there a reason not to just add 
>>> the new functionality to the existing tag? 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5380864a-642d-44f6-bd58-31c555a517a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi All,

I would like to propose a new template tag to be included in Django, it is 
sort of a cross between 'include' and 'extends'. You can find an 
implementation here: https://gist.github.com/samwillis/af3992f69c2597a16252

The main use case for this tag is being able to create reusable 
'components' for rendering a website. Say for example a page header, a 
panel with headers and footers, or a modal window (as seen in the Bootstrap 
framework). Rather than needing to repeat the html everywhere you need it 
and having to search out all occurrences to make a change to the structure 
you can create a simple template and include it.

To some extent this can currently be done with either an included template 
using the '{% include "template.html" with var="value" %}' syntax or using 
a custom template tag. However, the former isn't suitable for changing 
whole blocks in the include template, and the latter can be overkill and 
may not be suitable for a designer with little knowledge of Python and the 
Django Template API.

The 'use' tag loads a template and renders it with the current context 
similar to the 'include' tag. You can pass additional context using keyword 
arguments as well as override blocks in the included template.

Example (simple) template:


{% block heading %}{% endblock %}


Example 'use' tag use with the above template:

{% use "page_header.html" %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

{% use "page_header.html" with extra_class="large" %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

As with 'include' use the 'only' argument to exclude the current context 
when rendering the included template:

{% use "page_header.html" only %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

{% use "page_header.html" with extra_class="large" only %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

The included template receives an additional context variable called 
'used_blocks' which is a Dict indicating which blocks were overridden in 
the 'use' tag. Using this you can conditionally show content around the 
block. For example, if you had this template for generating a page heading:


{% block heading %}{% endblock %}
{% if used_blocks.sub_heading %}
{% block sub_heading %}{% endblock %}
{% endif %}


and included it using:

{% use "page_header.html" %}
{% block heading %}My Page Title{% endblock %}
{% enduse %}

it would exclude the '' tags from the empty subheading.

Finally, as syntactic sugar if you are just overriding a single block you 
can express it as:

{% use "page_header.html" block heading %}
My Page Title
{% enduse %}

These example are a little simple, but this could be incredibly useful for 
more complex components such a modal windows.

I have made a first pass at an implementation here: 
https://gist.github.com/samwillis/af3992f69c2597a16252.

Although I have implemented this with the 'use' word, there may be a better 
word. I considered 'embed' but thought 'use' was a little cleaner

Thanks,
Sam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0104008b-bb58-4730-a0dd-43c2875fa1b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.