Refactored tests to use a sample project.
Updated extraction:
* Removed special handling of single percent signs.
* When extracting messages from template text, doubled all percent signs
so they are not interpreted by gettext as string format flags. All
strings extracted by gettext, if containing a percent sign, will now
be labeled "#, python-format".
Updated translation:
* Used "%%" for "%" in template text before calling gettext.
* Updated {% trans %} rendering to restore "%" from "%%".
* Converted the ``libraries`` and ``builtins`` globals of
``django.template.base`` into properties of the Engine class.
* Added a public API for explicit registration of libraries and builtins.
With the introduction of multiple template engines these exceptions are no
longer DTL-specific. It makes more sense for them to be moved out of
DTL-related modules.
This change:
* Makes the InclusionNode cache-safe by removing render-time side effects
to its nodelist.
* Ensures the render_context stack is properly scoped and reset by updating
the render call to use Template.render rather than Nodelist.render.
This patch does three major things:
* Merges the django.template.debug implementation into django.template.base.
* Simplifies the debug implementation.
The old implementation copied debug information to every token and node.
The django_template_source attribute was set in multiple places, some
quite hacky, like django.template.defaulttags.ForNode.
Debug information is now annotated in two high-level places:
* Template.compile_nodelist for errors during parsing
* Node.render_annotated for errors during rendering
These were chosen because they have access to the template and context
as well as to all exceptions that happen during either the parse or
render phase.
* Moves the contextual line traceback information creation from
django.views.debug into django.template.base.Template. The debug views now
only deal with the presentation of the debug information.
Previously, when a template was rendered with RequestContext, inclusion
tags were rendered with a plain context, losing additional information
available in the RequestContext.
The (admittedly bizarre) implementation of RequestContext.new() has the
side-effect of not running template context processors, making this
change backwards-compatible.
This commit changes the return type of these two functions. Instead of
returning a django.template.Template they return a backend-specific
Template class that must implement render(self, context).
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.
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.
The docstring of FilterExpression said that it shouldn't be
instantiated from anywhere but the get_filters_from_token
helper function.
However, that helper function was deleted in commit
3ede006fc9 and FilterExpression
is instantiated from inside the compile_filter help function.
``get_template_from_string`` default arguments were breaking
``assertTemplateUsed``. The solution has been to return only the names of the
templates with a ``name`` attribute distinct of ``None``. The default ``name``
kwarg of ``Template`` has been changed to ``None``, more pythonic than ``'<Unknown
Template>'``.
This function is now the de facto standard function for rendering values in a
template, and is imported by two other built-in template modules. It shouldn't
have a leading underscore.
Wrap the Parser.compile_filter method call with a try/except and call the
newly added Parser.compile_filter_error(). Overwrite this method in the
DebugParser to throw the correct error.
Since this error was otherwise catched by the compile_function try/except
block the debugger highlighted the wrong line.
* Renamed the __unicode__ methods
* Applied the python_2_unicode_compatible decorator
* Removed the StrAndUnicode mix-in that is superseded by
python_2_unicode_compatible
* Kept the __unicode__ methods in classes that specifically
test it under Python 2
* Renamed smart_unicode to smart_text (but kept the old name under
Python 2 for backwards compatibility).
* Renamed smart_str to smart_bytes.
* Re-introduced smart_str as an alias for smart_text under Python 3
and smart_bytes under Python 2 (which is backwards compatible).
Thus smart_str always returns a str objects.
* Used the new smart_str in a few places where both Python 2 and 3
want a str.
Previously, the closing token for the verbatim tag was specified as the
first argument of the opening token. As pointed out by Jannis, this is
a rather major departure from the core tag standard.
The new method reflects how you can give a specific closing name to
{% block %} tags.
* It's the most micro of optimizations (forget I even said it)
* It makes significantly more sense semantically, given these are functions which return unicode.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16957 bcc190cf-cafb-0310-a4f2-bffc1f526a37