Hi Sam,
It seems that even your complete proposal with working code did not
receive any attention from the core developers at the time. It would
seem from that thread that Jonathan Slenders also made a similar
proposal / solution and it too was rejected. Well, his was at least
rejected - judging by his post.
Gathering such proposals in external projects like sniplates (proposed
by Curtis) seems like a good approach as long as the target library has
such enhancements in its scope. It would seem Curtis has issues
implementing stuff like that though: he proposed the same to you as
well, you allowed it, but it's not in his library.
Given the evidence, it seems there is no interest in core team to do
something like this. I am yet to figure out how decisions on feature set
are made: I have not found any document stating missions for various
django parts. Something like that could be very helpful in determining
whether to propose something to this list at all. It is difficult to
determine whether something would benefit from being in core django vs
in a separate library.
LP,
Jure
On 18/08/2020 17:57, Sam Willis wrote:
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
<https://getbootstrap.com/docs/3.3/components/#panels-heading>
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
<https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#include>
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
<mailto: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
<https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/bd6cdebe-14b4-bbee-bb1d-b87918537424%40gmail.com.
