| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
i18n is left aside for now.
|
|
Since this package is going to hold both the implementation of the Django
Template Language and the infrastructure for Multiple Template Engines,
it should be untied from the DTL as much as possible within our
backwards-compatibility policy.
Only public APIs (i.e. APIs mentioned in the documentation) were left.
|
|
The shorter name is just as explicit and, well, shorter.
|
|
|
|
Refs #7261 -- Made strings escaped by Django usable in third-party libs.
The changes in mark_safe and mark_for_escaping are straightforward. The
more tricky part is to handle correctly objects that implement __html__.
Historically escape() has escaped SafeData. Even if that doesn't seem a
good behavior, changing it would create security concerns. Therefore
support for __html__() was only added to conditional_escape() where this
concern doesn't exist.
Then using conditional_escape() instead of escape() in the Django
template engine makes it understand data escaped by other libraries.
Template filter |escape accounts for __html__() when it's available.
|force_escape forces the use of Django's HTML escaping implementation.
Here's why the change in render_value_in_context() is safe. Before Django
1.7 conditional_escape() was implemented as follows:
if isinstance(text, SafeData):
return text
else:
return escape(text)
render_value_in_context() never called escape() on SafeData. Therefore
replacing escape() with conditional_escape() doesn't change the
autoescaping logic as it was originally intended.
This change should be backported to Django 1.7 because it corrects a
feature added in Django 1.7.
Thanks mitsuhiko for the report.
|
|
comprehension
|
|
Since Python 2.7 and 3.1, "{0} {1}" is equivalent to "{} {}".
|
|
Thanks to Tim for the review.
|
|
|
|
|
|
Since RequestContext doesn't know its Engine until it's passed to
Template.render() -- and cannot without breaking a widely used public
API -- an elaborate hack is required to apply context processors.
|
|
|
|
|
|
|
|
It's only available during the rendering.
|
|
|
|
Passed the engine instance to loaders. This is a prerequisite for
looking up configuration on the engine instance instead of global
settings.
This is backwards incompatible for custom template loaders that override
__init__. However the documentation doesn't talk about __init__ and the
way to pass arguments to custom template loaders isn't specified. I'm
considering it a private API.
|
|
It was introduced in a recent refactoring so this isn't an issue.
Then renamed _get_template_loaders to get_template_loaders.
|
|
Moved Django templates loading infrastructure there.
|
|
Cancels 2f0566fa. Refs #4278.
|
|
This change preserves backwards-compatibility for a very common misuse
of render_to_response which even occurred in the official documentation.
It fixes that misuse wherever it happened in the code base and docs.
Context.__init__ is documented as accepting a dict and nothing else.
Since Context is dict-like, Context(Context({})) could work to some
extent. However, things get complicated with RequestContext and that
gets in the way of refactoring the template engine. This is the real
rationale for this change.
|
|
|
|
|
|
They were deprecated in Django 1.2 but not all the supporting code was
removed in Django 1.4. Since the remaining code was unlikely to be
functional (pun intended) e.g. it would crash unless the loader
function had an is_usable attribute, this commit completes the removal
immediately instead of starting another deprecation path.
|
|
This ensures that enabling the cached loader doesn't change behavior.
(Before this commit, it did when the list contained unusable loaders.)
|
|
This provides the opportunity to move utility functions specific to the
Django Template Language outside of django.template.loader.
|
|
|
|
It didn't account for class-based template loaders.
|
|
This change has the nice side effect of removing code that ran at import
time and depended on the app registry at module level -- a notorious
cause of AppRegistryNotReady exceptions.
|
|
It didn't do anything, wasn't documented and wasn't used anywhere.
|
|
Since it isn't branded as a test utility any more and could be used for
other purposes than test code, that prefix no longer makes sense.
It wasn't used anywhere either.
|
|
Reformatted the code of base.Loader according to modern standards.
Turned the test template loader into a regular locmem.Loader -- but
didn't document it.
Added a normal deprecation path for BaseLoader which is a public API.
Added an accelerated deprecation path for TestTemplateLoader which is
a private API.
|
|
Removed misleading comment and provide correct one, explaining
idea behind hardcoded CSRF template context processor.
|
|
http.cookie.
This fix is necessary for Python 3.5 compatibility (refs #23763).
Thanks Berker Peksag for review.
|
|
`io.open` is required on Python 2.7. Just `open` would work on Python 3.
|
|
Added a test for the condition safe_join is designed to prevent.
Previously, a generic ValueError was raised. It was impossible to tell
an intentional exception raised to implement safe_join's contract from
an unintentional exception caused by incorrect inputs or unexpected
conditions. That resulted in bizarre exception catching patterns, which
this patch removes.
Since safe_join is a private API and since the change is unlikely to
create security issues for users who use it anyway -- at worst, an
uncaught SuspiciousFileOperation exception will bubble up -- it isn't
documented.
|
|
|
|
|
|
|
|
|
|
refs #23395.
|
|
This can help when some exception has no error message.
|
|
Thanks to Simon Charette, Aymeric Augustin, and Tim Graham
for reviews and contributions.
|
|
|
