| Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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 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.
|
|
Thanks Clueless for the initial patch.
Note that unittest has been purposely left out (external package only used by Python 2.6).
|
|
Thanks Bradley Ayers for the report.
|
|
for the sake of clarity. Cheers to Aymeric Augustin for bearing with me.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17107 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
For more information on this project, see this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/cf0423bbb85b1bbf
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17106 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
Thanks to Justin Myles-Holmes for report and draft patch.
Exceptions raised in templates were previously wrapped in TemplateSyntaxError
(in TEMPLATE_DEBUG mode only) in order to provide template source details on
the debug 500 page. The same debug information is now provided by annotating
exceptions rather than wrapping them. This makes catching exceptions raised
from templates more sane, as it's consistent in or out of DEBUG, and you can
catch the specific exception(s) you care about rather than having to also catch
TemplateSyntaxError and unwrap it.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16833 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
exception happening in one of the loops. Thanks, Charmless and vladmos.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16605 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
the work on the patch and Alex for reviewing.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16539 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
to help with avoiding circular import dependencies. Thanks to Tom Tobin for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14722 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
Thanks to Adam McKerlie for the report.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14397 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
disabled in a template. Thanks to Benjamin Wohlwend for the work on the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14395 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
an exception is encountered during template rendering, even when running on Python 2.6 or higher. Thanks Glenn.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@12725 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
(dates and numbers) and form processing.
Thanks to Marc Garcia for working on this during his Google Summer of Code 2009!
Additionally fixes #1061, #2203, #3940, #5526, #6449, #6231, #6693, #6783, #9366 and #10891.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11964 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
Combined work from Karen Tracey and Thomas Güttler.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7260 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
debug.py, so they're only loaded if DEBUG=True. This led to a DEBUG=False memory savings of one 4-KB memory block on my machine, according to ps
git-svn-id: http://code.djangoproject.com/svn/django/trunk@6969 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|