Re: include_block template tag

[Pierre Vanliefland]

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


  {% embed "section.html" %}
{% block title %}Stats{% endblock %}
{% block content %}
   
  A stat
  ...
   
{% endblock %}
  {% endembed %}
  {% embed "section.html" %}
{% block title %}Activity{% endblock %}
{% block content %}
   Yesterday
   All my troubles seem so far away
{% endblock %}
  {% endembed %}


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

Re: include_block template tag

[Carlton Gibson]

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  
> 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:
> Needs very little code
> 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:
> 
> 
>   {% embed "section.html" %}
> {% block title %}Stats{% endblock %}
> {% block content %}
>
>   A stat
>   ...
>
> {% endblock %}
>   {% endembed %}
>   {% embed "section.html" %}
> {% block title %}Activity{% endblock %}
> {% block content %}
>Yesterday
>All my troubles seem so far away
> {% endblock %}
>   {% endembed %}
> 
> 
> 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 
> ).
> 
> 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
> 
> 
> 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-part