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-develop...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2b317d14-f8e1-c47d-4883-ff06040d1204%40gmail.com.
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
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com.
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.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com.
Final comment for this:
we implemented the tag in our dynamicforms library (commit with initial implementation).
The initial implementation straight-out replaces the django include tag, giving it an additional option to also declare a block tag with nested blocks. That didn't work on Django 2.2. though, so the final implementation now splits the tag in block and non-block variants.
Anyway, I wanted to say that initial implementation wasn't much feature-creep on the include tag anyway. It should be a very small PR that would eliminate a huge disclaimer in documentation in exchange for a couple (literally) lines of new code.
TL;DR:
So: having implemented this, I'd say that code feature-creep is cheaper than documentation / support effort needed to explain away demands for the functionality?
Curtis, you're free to use this in your Sniplates. I'd just warn about the helper function parse_tag which we got here and don't know the license of, yet. We will get rid of it ourselves if there's no reply shortly, but it was convenient when programming the tag :).
To also attempt answer Carlton's fears / second thoughts: this
form of the tag gives you content / presentation separation in
your template. Your main template contains and provides all the
data required for displaying and you then display it by including
the actual rendering template, giving it the content in content
blocks. This way you can easily swap presentation without having
to swap an entire page's worth of template. Very easy to do "view
result" vs "view code" in your templates then to give one example.
In our templates we use it to seamlessly switch between various
CSS frameworks that we support.
LP,
Jure
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D9AF6228-F579-43B7-B6C4-DBDC91DF4031%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fbc48cf4-2835-4c94-be7a-8ee32f4d10a5n%40googlegroups.com.
Hi Pierre,
I like your solution very much: implements what needs to be implemented, rationalises it very well and also adds all the other bits'n'pieces required for a proper PR.
I really hope this gets accepted, it was a huge thorn in our
butts until we implemented it. Now we're (ab)using it everywhere.
LP,
Jure
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7f3580c9-8c76-493a-89f3-5417876e4a9bn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5ac258af-8519-4b83-9953-36e7120d2696n%40googlegroups.com.