2014-12-29 4:53 GMT+01:00 Preston Timmons <[email protected]>:
> Did that explain it better? If not, I can try again. :) > Yes, I understand better now. The debugging information is two dimensional data: for each level of template extending, for each template loader, you have one entry — entries are 4-uples in your current proposal. The format you described is a flattened view of this list. That's good because it avoids encoding the concepts of "template extension" or "template loader" in the API, keeping it generic. If entries contain the template identifier i.e. the string you pass to get_template then the two dimensional view can almost be reconstructed — almost because it won't detect when a template extends another template with the same name, the very feature you're working on adding... At this point, I think we should talk about template origins. What is their purpose? What is the complete abstract Origin API? The current API only includes a `name` attribute and an unspecified `reload()` method; I don't think that's sufficient. I will audit current uses of Origin in Django. Could you specify the requirements for objects yielded by get_template_sources? Then we'll see if they're compatible. If we can avoid introducing a new concept, that's always better. Thanks, -- Aymeric. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mV1XZUtcNoZFLxa%2BH8AHftHNVOgjZF%3DO4wahMdQM4JrTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
