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
On 17. 04. 21 10:23, Pierre Vanliefland wrote:
Hi Carlton,
Thanks for replying so quickly. It's definitely been an itch for me,
as check the docs and Stack Overflow every year to check if this has
been implemented!
I've completed the Gist with an "include/extends" example, but I
haven't done the same for inclusion tags: as far as I know, an
inclusion tag has a single, fixed template, which would require you to
create one inclusion tag by component in your "design system", which
would be even more cumbersome. And it would not allow you to override
multiple block contents with arbitrary HTML, which is the goal here.
I plan to use my own implementation more extensively in the coming
weeks to check its robustness, but I would be super happy to propose a
PR if you find it interesting.
At the moment, it's not a big pain point for me, as I can use my
custom tag, but I agree with the feeling of Carl above: while useful,
it's a small feature and I'm afraid users won't be attracted by a
third-party plugin for 50 lines of code...
I was wondering why I was feeling like this is a missing piece, and I
remembered this morning: I used this feature a lot when I was using
Twig (https://twig.symfony.com/doc/3.x/tags/embed.html).
It was super useful, especially when working on a web application (vs
website), where you have a lot of similar sections and widgets, and
I've been missing it a lot over the years.
Have a nice day!
Pierre
On Saturday, April 17, 2021 at 5:44:05 AM UTC+2 carlton...@gmail.com
wrote:
Hi Pierre,
No problem at all! There’s some itch that folks have here so all
for the good discussing it.
Thanks for your work on the gist it looks good. I just glanced at
it now, and need to sit down longer but, can I ask you to add a
“What’s wrong with the current tools” section to text? i.e. How
would it look using include or a custom inclusion tag, and so why
would a new tag be better? I think that would be helpful. (Make
sense?)
Kind Regards,
Carlton
On 16 Apr 2021, at 23:03, Pierre Vanliefland
<pierre.va...@gmail.com> wrote:
Hello! First, sorry if it is not appropriate to bring back this
thread from the grave, but I spent some time on finding a
solution for this and came up with an implementation that:
1. Needs very little code
2. Re-uses the existing code for the extends and include tags
I have written a Gist that contain the full code (including text)
and a bit of context:
https://gist.github.com/pvanliefland/bb676a906b900c7e29e46b474038a6ca
<https://gist.github.com/pvanliefland/bb676a906b900c7e29e46b474038a6ca>
Do you think this is worth discussing here?
*Usage:*
<body>
{% embed "section.html" %}
{% block title %}Stats{% endblock %}
{% block content %}
<ul>
<li>A stat</li>
...
</ul>
{% endblock %}
{% endembed %}
{% embed "section.html" %}
{% block title %}Activity{% endblock %}
{% block content %}
<h2>Yesterday</h2>
<p>All my troubles seem so far away</p>
{% endblock %}
{% endembed %}
</body>
On Wednesday, December 2, 2020 at 9:51:03 AM UTC+1
jure.er...@gmail.com <http://gmail.com> wrote:
Final comment for this:
we implemented the tag in our dynamicforms library (commit
with initial implementation
<https://github.com/velis74/DynamicForms/commit/c65588b0423fe49ebfc141e4a5016abc74d4e854>).
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
<https://www.caktusgroup.com/blog/2017/05/01/building-custom-block-template-tag/>
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
On 19. 08. 20 18:08, Carlton Gibson wrote:
Hey Sam.
(“I” is a placeholder in what follows…)
What I’m missing here, personally, having read this thread,
and the old-one is motivating examples where I go "wow,
yeah, that would really make my life easier”.
I read it and think yeah maybe. I see a couple of positive
comments from people who’s judgement I would trust. But I
STILL don’t really see what I’d gain. (I could spend hours
thinking over it but it’s not clear I have that time.)
Then I see Curtis, who’s judgement I do trust, saying “I
have this (or similar) working in my package over here”. I
then think, well let’s push forward with that, and I’ll put
it on the list to check out next time I need something in
this ballpark. (Not a placeholder: I think I recall Curtis
showing me this package in Florence a few years ago, but I
have to admit to forgetting about it until this thread came
up.)
I suspect it’s not really that pressing: after all this
time, maybe a custom tag is good/easy enough…? — the recent
survey showed that people aren’t abandoning the DTL on mass:
the lack of this feature doesn’t seem to be enough to make
people jump ship.
Maybe this is the missing feature, but can be show WHY it
would be so good?
I think compelling use-cases gain converts. The advantage of
the third-party package is it allows that to be worked out,
outside the main development cycle, which is so slow, and
had such strong backwards compatibility constraints that we
simply can’t take things which are fully worked out… — it
has to be right, or there about when we first take it.
C.
On 19 Aug 2020, at 15:34, Sam Willis <sam.w...@gmail.com>
wrote:
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 <http://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 todjango-develop...@googlegroups.com.
To view this discussion on the web
visithttps://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%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-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/D9AF6228-F579-43B7-B6C4-DBDC91DF4031%40gmail.com
<https://groups.google.com/d/msgid/django-developers/D9AF6228-F579-43B7-B6C4-DBDC91DF4031%40gmail.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-develop...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/fbc48cf4-2835-4c94-be7a-8ee32f4d10a5n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/fbc48cf4-2835-4c94-be7a-8ee32f4d10a5n%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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7f3580c9-8c76-493a-89f3-5417876e4a9bn%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/7f3580c9-8c76-493a-89f3-5417876e4a9bn%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/c286fbcc-f7ca-dcc7-196c-38a0e083a5f9%40gmail.com.
