>
> The debugging information is two dimensional data: for each level of
> template extending, for each template loader, you have one entry —
> entries are 4-tuples in your current proposal.
Yes, this is correct. Although there may not be an entry for each loader on
each level of extending. The looping stops if a matching template is found.
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.
Origin currently has these attributes:
name
For filesystem and app loaders this is the full path to the template.
For the egg loader this is "egg:<app_config.name>:<pkg_name>".
For locmem this is just the template name.
loader
This is the load_template_source method of the loader that found the
template.
loadname
This is the original template_name used for load_template_source.
dirs
This is a deprecated value set when dirs is passed to get_template.
reload
This is used by the debug views to get the source content of the template.
It
calls self.loader--which is really load_template_source--with loadname and
dirs.
My branch makes some changes to this class. (Note: this will change a bit if
get_template_sources returns an origin instead)
1. name is the value as returned by get_template_sources. For filesystem and
app loaders this is still the full path. For the egg and cached loaders
it's
a tuple (app_config.name, template_name) or (loader, source).
2. loader is changed to reference the loader instance rather than the
load_template_source method.
3. A tried attribute is added. This is the same format as passed to
TemplateDoesNotExist.
4. reload is updated to call loader.get_internal when available, otherwise
it falls back to loader.load_template_source.
This is what I use origin for:
1. I add origin.name to the loader extends history. This enables the current
template to be skipped rather than re-extended.
2. If an extended template is found, the new origin.name is added to the
extends history. Also, the original origin.tried and new origin.tried are
combined to give a complete list of templates found before and after
extending.
3. If an extended template isn't found, the TemplateDoesNotExist tried value
is combined with the original origin.tried to give a complete list of what
templates were tried before failing.
4. Loader.get_template sets tried on origin with the values returned by
get_template_sources.
## Potential changes
If get_template_sources is changed to return an origin, it seems to make
sense
that "tried" would simply be a list of origins instead of a 4-tuple. There
would need to be a status attribute added. This would default to None since
we
don't know the status until get_internal is called.
"tried" currently lives on origin. This seems weird to me since origin.tried
would contain a reference to itself. It would probably be better to move
that
to the template object. The extends node would then access the list of
origins
up to that point, rather than just the current origin.
The extends history would be simplified a bit. Currently, it's a dict that
tracks history for each loader. This is done to eliminate any possible
clashes
if two template loaders return the same source value. This could be updated
to
just be a list of origins.
It's sufficient for my patch if origin has these values:
origin.name -> the source path - may be a string, tuple, model instance,
etc.
origin.loader -> the template loader
origin.loadname -> the template_name value
origin.status -> the status of the template. This is set after get_internal
is
called.
origin.loader_name -> returns a string representation of the loader class.
This
is used in the debug view postmortem.
## Other template engines
If "tried" is a list of origins, the other template engines would need to
use
the origin class if they display a postmortem.
In order to get a correct string representation of the underlying loader in
the
postmortem, engines could subclass Origin and implement a custom
loader_name method. Using Origin then should be similar to using the tuple.
I don't think it will cause any tie-in to Django-specific loaders.
Would origin.reload be used for other engines? If so, it could also be
added in
the subclass. I'll have to take some time to understand how the traceback
works
before I could comment much on this, though.
Thanks.
Preston
--
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/d99f1676-3a71-4045-aa86-2f3c944ada29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
