Hi there!
> In fact, it allows arbitrary nesting and combinations. It works by
> keeping a list of possible sources for each template and as template
> is rendered it removes it from the list, so that next time it is not
> loaded anymore.
I'm not entirely convinced about maintaining a dicts of li
Hi!
I just discovered this thread on the mailing list. I implemented also
template recursion in this modified django-overextends:
https://github.com/wlanslovenija/django-overextends/blob/nested-extends/overextends/templatetags/overextends_tags.py
It supports all possible combinations. For exampl
Hi there!
> I'm working on an other solution that instead of relying on loader
> skipping relies on template skipping.
Sorry for keeping you waiting on updates for so long!
I was able to put some time into it today. Although it isn't nothing
definitive and testing, benchmarking and docs are miss
Hi there!
> Florian, I know that the benefits of this solution. But I see the
> detriments too. I think that if we allow that a app template
> overwrite with self-reference another app template the template
> development will be a chaos. I thought alot about it
Well, I agree that if miss used, th
Florian, I know that the benefits of this solution. But I see the
detriments too. I think that if we allow that a app template overwrite with
self-reference another app template the template development will be a
chaos. I thought alot about it
2013/12/9 Florian Apolloner
> Just as a good example
Just as a good example on why it's not a good idea to skip a loader:
Grappelli could most likely strongly benefit from this feature and their
preferred setup looks like this
http://django-grappelli.readthedocs.org/en/latest/quickstart.html#setup --
Having to set TEMPLATE_DIRS to the grappelli t
On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote:
>
> 2013/12/9 Florian Apolloner >
>
>> On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote:
>>>
>>> 1. Efficiency: If this new solution slows the compilation/find/render
>>> template, I dislike it
>>>
>>
>> Lots of "ifs" which
2013/12/9 Florian Apolloner
> On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote:
>>
>> 1. Efficiency: If this new solution slows the compilation/find/render
>> template, I dislike it
>>
>
> Lots of "ifs" which are not really worth discussing before we run actual
> benchmarks; also I thi
> I read Pablo's concern as: If the skipping is done in each loader,
> does "recursive" self-reference work across loaders?
Uh, I didn't understand, of course you can ;-)
Imagine you are extending an app template from within a project template and
that the order of the loaders is [dirs, app]. Wel
On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote:
>
> 1. Efficiency: If this new solution slows the compilation/find/render
> template, I dislike it
>
Lots of "ifs" which are not really worth discussing before we run actual
benchmarks; also I think that it won't be slower since curren
On Monday 09 December 2013 14:58:34 unai wrote:
>
> > 2. This solution will complicate the template development. e.g. if a
> >
> > application overwrite the "admin/change_form.html" template and a
> > developer wants to update this template, he will have to search this
> > template in every app
Hi!
> 1. Efficiency: If this new solution slows the compilation/find/render
> template, I dislike it
Well, if there is no self-referenced inheritance, no extra code (except for the
very same self-referenced inheritance check) is executed, so there is that.
If self-referenced inheritance is foun
On Saturday, 7 December 2013 01:36:00 UTC+11, unai wrote:
>
> Hi!
>
> Pablo Martín (goinnn[0]) and I have been working on self-referenced
> template
> recursion handling for the past few weeks. The idea is that when a
> template
> references itself when extending,
2013/12/8 unai
> Hello,
>
> > given this approach, what if the third party app wants to self-extend
> > a django admin template for example?
>
> I'm working on an other solution that instead of relying on loader skipping
> relies on template skipping.
>
> Imagine you extend to a self-reference fr
Hello,
> I tend to warn people off thinking of template names as paths. It's
> an implementation detail that they are treated as such by the two
> default loaders.
> Requiring each loader to include an unique id with each template
> (even if it's just a full path) seems the easiest solution.
> O
unai wrote:
>Hello,
>
>> given this approach, what if the third party app wants to self-extend
>> a django admin template for example?
>
>I'm working on an other solution that instead of relying on loader
>skipping
>relies on template skipping.
>
>Imagine you extend to a self-reference from within
Hi all,
If anybody's interested in some background reading, there is an
implementation of this in Mezzanine, using an "overextends" tag.
https://github.com/stephenmcd/mezzanine/blob/1.4.16/mezzanine/template/loader_tags.py
Cheers,
Alex
On Sunday, December 8, 2013 11:08:12 PM UTC+8, unai wrote:
Hello,
> given this approach, what if the third party app wants to self-extend
> a django admin template for example?
I'm working on an other solution that instead of relying on loader skipping
relies on template skipping.
Imagine you extend to a self-reference from within a template. All the
te
Pantelis
On 12/06/2013 04:36 PM, unai wrote:
Hi!
Pablo Martín (goinnn[0]) and I have been working on self-referenced template
recursion handling for the past few weeks. The idea is that when a template
references itself when extending, recursion is avoided by skipping the current
template l
2013/12/8 Jonathan Slenders
> Do we ever intend to implement something like collect_templates in the
> future? Similar to collect_static?
>
I think that for this reason exists the cache template loader, it is
something similar. With this template loader every template is only
compiled one time.
2013/12/7 Florian Apolloner
> Hi,
>
> there is no need to convince us that this feature would be nice to have;
> the ticket is accepted…
>
Yes this ticket is accepted, but this is accepted from 3 years ago... I
think that everybody knows that the current solution needs to improve in
the self-re
Do we ever intend to implement something like collect_templates in the
future? Similar to collect_static?
If so, implementing this would break collect_templates or the similarity
that we currently have in how app directories are processed.
This is actually the monkey-patching way of writing templ
Hi,
there is no need to convince us that this feature would be nice to have;
the ticket is accepted… I left a comment on the ticket page; and I think we
should do this in one patch instead of two, so we can get the API right
(Especially since I am not sure if skipping the loaders is the correct
2013/12/6 German Larrain
> On Friday, December 6, 2013 11:36:00 AM UTC-3, unai wrote:
>>
>> Lot of app/CMS creators create base templates for their apps. Currently,
>> if one
>> of those templates needs some kind of change, the user needs to copy the
>> template all over again, making it difficul
On Friday, December 6, 2013 11:36:00 AM UTC-3, unai wrote:
>
> Lot of app/CMS creators create base templates for their apps. Currently,
> if one
> of those templates needs some kind of change, the user needs to copy the
> template all over again, making it difficult to update their templates
>
Hi!
Pablo Martín (goinnn[0]) and I have been working on self-referenced template
recursion handling for the past few weeks. The idea is that when a template
references itself when extending, recursion is avoided by skipping the current
template loader (ticket #15053[1]).
This new feature would
26 matches
Mail list logo
