jbalogh / jingo Goto Github PK

There have been some patches added to jingo that are not in version 0.7.
Would it be possible to do a release?

django/django@af64429 adds support for __html__

I am trying to use Sitemap framework and getting Encountered unknown tag 'spaceless'. error.

When I add 'sitemap' to JINGO_EXCLUDE_APPS, it still shows same error, so it seems template is still proccessed by Jingo/Jinja2.

Hi,
jingo without any extra configuration doesn't translate texts in templates. In documentation isn't any notice about this behaviour. Issue arise because jingo in default config install null translation in jinja2 enviroment (https://github.com/jbalogh/jingo/blob/master/jingo/__init__.py#L70).

For resolving issue you must install gettext translation:

from django.utils import translation
from jingo import env
env.install_gettext_translations(translation)

Comment before install_null_translations() says that call is important for testing, so we should choose cautious solution. May be create some optional setting for these cases and definitely write down documentation.

When two apps in INSTALLED_APPS are trying to access (when loaded, app/__init__.py) to the Jinja2 Environment jingo.env, a circular import occurs. This is caused by Jingo, which try to import this apps in the get_env method.

This could be easily solved caching env in get_env.

The master branch has an important fix for Django 1.7.

It's worth a tag & a release to PyPI.

Since b40ccfc#diff-ef2d1aabcfb813b2ee524b54f1a93742L26 the helpers.f helper doesn't convert its input to a string before doing the string interpolation, like it used to.

This conversion, however, is still done in helpers.fe.

This causes issues when the input is a jinja2.Markup object, which automatically escapes anything that is string interpolated with it.

This happens, for example, if you're using https://github.com/clouserw/tower/, which returns a jinja2.Markup object for localized strings:

{{ _('this is {0}')|f('<b>markup</b>') }}

This is supposed to return This is <b>markup</b>, but instead returns This is <b>markup</b>

Django 1.7 causes jingo to break in at least one way that I've found so far.

StrAndUnicode was deprecated in 1.5 and removed in 1.7. Jingo uses this method in monkey.py. The replacement, which is to use the @python_2_unicode_compatible class decorator wouldn't work with the class base hacking that jingo does. I'm investigating a way to solve this in a backwards compatible way.

We have the override kwarg for register.function but not register.filter. Seems like we should do both.

Django's direct_to_template allows setting the template, mimetype, and extra_context: http://docs.djangoproject.com/en/dev/ref/generic-views/#django-views-generic-simple-direct-to-template

Jingo, instead takes the dictionary it is fed as kwargs and drops its content directly into the context. This makes setting the mime type impossible.

The test suite when it sets up the site monkey patches template rendering so that it sends the right signal that test suite needs. That signal is then caught and populates things like request.context so you can examine them in a test.

However the monkey patch inside django tests, patches the _render method. Jingo doesn't call that. Instead it relies upon the TEMPLATE_DEBUG flag to be set if it is, it calls the signal.

The upshot is, if you don't set TEMPLATE_DEBUG in your tests, request.context ends up as None. Ideally we'd use a _render method in jingo so we can detect when the signal is being added.

Another developer had a problem with our project and we tracked it down to jingo's datetime filter.

The default format string is %B %e, %Y. It uses %e which is not available on all platforms (according to this list in the Python documentation). I guess replacing that by %d should be enough (although that adds a leading zero).

import datetime; x = datetime.datetime(2012, 12, 3, 12, 1, 34); x.strftime('%e') raises a ValueError exception, invalid format string.

>>> print platform.platform()
Windows-XP-5.1.2600-SP3

If I genering form with {{ form.as_p() }} html code is automatically escaped. This is obviously solvable by {{ form.as_p()|safe }}, but this is ugly solution. Is there a better way?

"We should roll an @inclusion_tag like Django has." --jbalogh

Right now the override kwarg on register.function (doesn't exist on filter, filing that next) defaults to True. That essentially means the behavior is "register this function unless something has already registered a function of this name".

That is a great way to introduce subtle bugs. It seems like we should default to False and even consider issuing a warning or raising an exception if a second function tries to register without overriding. That would make such errors screamingly obvious.

In our massive update from Django 1.4 to 1.7, I caught our jingo.monkey patch call in manage.py using a removed feature of Django?

Traceback (most recent call last):
  File "./manage.py", line 46, in <module>
    import jingo.monkey
  File "/home/vagrant/src/vendor/src/jingo/jingo/monkey.py", line 60, in <module>
    class SafeStrAndUnicode(django.utils.encoding.StrAndUnicode):
AttributeError: 'module' object has no attribute 'StrAndUnicode'

StrAndUnicode was deprecrated in 1.5 and is removed as of 1.7.

Jingo continues to be a central part of the Django sites at Mozilla and is currently blocking the upgrade to the current Django LTS release as well as the use of modern Django techniques.

Since there is a history of slow responses from the maintainers I'd like to propose myself as another team member to be able to deliver faster releases that work on current Django releases.

Alternatively (which I would prefer) let's transfer the whole app to the mozilla namespace and spread the workload to the rest of the webdevs/webengs at Mozilla. This is an essential part of the success of our sites and should serve as a reminder that OSS often also means to step up when the original authors are not able to support maintenance in their spare time.

Given Django 1.8's own Jinja2 support I would estimate a big chance to make Jingo a thin wrapper around that feature lowering the maintenance burden even further.

@jbalogh @jsocol Opinions?

File "/usr/lib/python2.7/site-packages/jingo/init.py", line 11, in
from django.template.base import Origin, TemplateDoesNotExist
ImportError: cannot import name TemplateDoesNotExist

One of the pain points of jingo is the autodiscovery (a pattern that was much more en-vogue in Django when this was new). Changing the functions and filters in the helpers module to be installed via Jinja extension removes a bit of import contortion, and makes them easier to steal and install into another project, if you want to—for example if you're moving from jingo to django-jinja.

This is explicitly a step in the direction of obsoleting this project.

This works in regular django:

from django.test import TestCase
from django.template.loader import render_to_string
from django.template import Context


class SimpleTest(TestCase):

    def test_render_to_string(self):

        context = {'name': 'Peter'}
        html = render_to_string('homepage/test.html', context)
        assert 'Name:Peter' in html

        ccontext = Context(context)
        html = render_to_string('homepage/test.html', ccontext)
        assert 'Name:Peter' in html

But if fails when using jingo. It fails when the context parameter is a real subclass of the Context class.
The documentation says you're supposed to be able to pass either a dict or a Context instance.
https://docs.djangoproject.com/en/dev/ref/templates/api/#the-render-to-string-shortcut

The traceback is this:

Traceback (most recent call last):
  File "/Users/peterbe/dev/DJANGO/django-peterbecom/apps/homepage/tests.py", line 15, in test_render_to_string
    html = render_to_string('homepage/test.html', ccontext)
  File "/Users/peterbe/virtualenvs/peterbecom2/lib/python2.7/site-packages/django/template/loader.py", line 171, in render_to_string
    return t.render(Context(dictionary))
  File "/Users/peterbe/virtualenvs/peterbecom2/lib/python2.7/site-packages/jingo/__init__.py", line 172, in render
    context_dict.update(d)
ValueError: dictionary update sequence element #0 has length 1; 2 is required

The relevant code is this:

class Template(jinja2.Template):

    def render(self, context={}):
        """Render's a template, context can be a Django Context or a
        dictionary.
        """
        # flatten the Django Context into a single dictionary.
        context_dict = {}
        if hasattr(context, 'dicts'):
            for d in context.dicts:
                context_dict.update(d)
        else:
            context_dict = context
        ...

Hello,
there is subtle issue with using django admin and jingo. I add to my config:

JINGO_EXCLUDE_APPS = (
    'admin',
)

core of administration works, but if I want change password or logout server returns HTTP 500 because template was rendered by jinja2. I investigate it and working solution is set:

JINGO_EXCLUDE_APPS = (
    'admin',
    'registration',
)

But this is confusing registration isn't app, its one of template's dirs in django admin app. JINGO_EXCLUDE_APPS actually didn't work on app level, but only on template path level. Should be nice rename config variable or mention this behaviour in readme.

Django 1.7 introduced using 'django.contrib.admin.apps.SimpleAdminConfig' as an entry in INSTALLED_APPS. Jingo passes INSTALLED_APPS to jinja2.PackageLoader which tries to load them as Python packages. This fails when using SimpleAdminConfig because SimpleAdminConfig is not a Python module.

https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.autodiscover

There are many failed tests when running ./manage.py test.

It can be fixed by adding following JINGO_EXCLUDE_APPS into settings:

JINGO_EXCLUDE_APPS = (
    'admin',
    'registration',
    'context_processors',
)