>
> Perhaps we’ll bikeshed names at some point but let’s leave the “naming
> things” problem aside for now.
> “name” must be optional for loaders that don’t load templates from
> files.
> “loadname” must be optional too for templates instantiated from
> strings.
> Here optional means that things don’t break if the value is None.
If we combine LoaderOrigin and StringOrigin, then yes, it makes sense for
these to be optional. The origin will then gain an additional "source"
attribute from StringOrigin.
I don’t like the code duplication between get_internal and
> load_template_source. I assume your design ended up that way because
> you needed get_internal and load_template_sources will be deprecated.
> Is this correct?
Correct.
To minimize duplication I can modify load_template_sources to use
get_internal.
The test suite won't hit this code path anymore, though. That means I should
probably add additional tests to cover the deprecated methods.
That leaves the cached loader. If we modify Loader.load_template to
call Loader.get_template when get_internal is available, then I think the
cached.Loader.load_template and cached.loader.find_template methods can be
safely removed.
I'll go ahead and make these updates in the branch.
TemplateDoesNotExist is used both internally by the DTL and in generic
> APIs such as django.template.loader.get_template. If it’s designed to
> accept a list of tried origins, then we need:
> - a generic Origin without engine, loader, status and tried (at least)
> - a DTL Origin as described above.
> Does this make sense?
I think this is fine. "tried" and "loader" are internal concepts to Django.
If an engine is able to support the post-mortem an origin needs only to be
able
to return a string representation of the load method and a status. These are
optional if the engine can't provide this information.
Yes. Maintaining compatibility with LoaderOrigin as documented in 1.7
> appears to be a lost cause anyway.
Okay.
I think the appropriate way for origins to return template code would
> be to
> call back into the template loaders. Reading template contents in the
> job
> of the loader. It should be possible to write a single origin class
> that works
> for most loaders.
> The sole purpose of the reload() method is to display tracebacks in
> templates.
> This logic should be moved out of the debug view and into the template
> backends. See #24119. As a consequence, we should leave it outside of
> this
> refactoring and simply preserve it for DTL origins until that ticket
> gets fixed.
Sounds good.
If you’re going to change both its arguments and its return type, you
> can change
> the method's name :-) The second solution looks better to me.
> Hopefully we can
> write a “just do this” guide to help people maintaining custom
> template loaders
> upgrading.
Okay. I'll post back when I've implemented things further.
--
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/1bbd1aed-5732-470c-bc52-00a78052b10e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
