Hi Pierre,
I have been silently watching your progress with great enthusiasm. This
limitation of the DTL has been a thorn in my side for years. Are you able
to share any updates about your progress?
Cheers
Kye
On Friday, April 23, 2021 at 3:00:50 PM UTC+8 Pierre Vanliefland wrote:
> Hi Carlton,
>
> That would make sense. I'll keep testing/playing with it for the next few
> days, and will package it afterward.
>
> Kind regards,
>
> Pierre
>
> On Friday, April 23, 2021 at 6:19:34 AM UTC+2 carlton...@gmail.com wrote:
>
>> Hi Pierre.
>>
>> If you were to bundle it in a package and put in on PyPI, that would
>> allow others to easily experiment and feedback too.
>>
>> Kind regards, Carlton
>>
>> On Thu, 22 Apr 2021 at 21:33, Pierre Vanliefland <pierre.va...@gmail.com>
>> wrote:
>>
>>> Thanks Jure! In the meantime, I have started testing my code extensively
>>> and spotted a few problems, mostly linked to the usage of block nodes
>>> within {% embed %}.
>>>
>>> I have decide to use a new tag, {% slot %}, with a much simpler
>>> implementation and it seems to work just fine. I have updated the gist
>>> <https://gist.github.com/pvanliefland/bb676a906b900c7e29e46b474038a6ca>
>>> accordingly. I also have ditched the idea of reusing existing Django code
>>> (it was messy and confusing) but I have commented the code sections that
>>> are 100% identical to existing Django code, they could one day be
>>> refactored into helper methods / abstract classes.
>>>
>>> I plan to test this and release it in a production project over the next
>>> few weeks, I'll share my findings here after that.
>>>
>>> Kind regards,
>>>
>>> Pierre
>>>
>>> On Monday, April 19, 2021 at 11:16:08 AM UTC+2 jure.er...@gmail.com
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>> 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 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 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-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
>>>>>>
>>>>>> <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-develop...@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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/5ac258af-8519-4b83-9953-36e7120d2696n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/django-developers/5ac258af-8519-4b83-9953-36e7120d2696n%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/3ecbdace-b2d8-430a-83cd-83b7b6fb1f58n%40googlegroups.com.
