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.wil...@gmail.com
<mailto:sam.wil...@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-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@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-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/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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/aa5769fd-48a4-928e-653c-29e2b8d87386%40gmail.com.
