nyaruka / django-hamlpy Goto Github PK

View Code? Open in Web Editor NEW

This project forked from jessemiller/hamlpy

60.0 60.0 14.0 763 KB

Haml like templates for Django!

License: MIT License

Python 93.11% HTML 6.89%

django haml templating

django-hamlpy's People

Contributors

Stargazers

Watchers

Forkers

rvanlaar miki95xmmrx tanveerahmad1517 umarmughal824 library-collections takundac devxpy postelo sanshain andrewhawes felixschl reidlitkauo olivergs aagje-info

django-hamlpy's Issues

Ignore spaces after filter name

E.g. :css followed by space on the same line throws error as it can't find a filter called "css "

Django template loader not working in 1.10?

I'm unable to get the template loader to work in Python 3.4.3, Django 1.10. The templates end in .haml and are rendered but the haml is not converted to HTML.

Settings file for templates looks like:

TEMPLATES = [
  {
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': ["web/templates"],
    'APP_DIRS': False,
    'OPTIONS': {
      'context_processors': [
        'django.template.context_processors.debug',
        'django.template.context_processors.request',
        'django.contrib.messages.context_processors.messages',
      ],
      'loaders': [
        'hamlpy.template.loaders.HamlPyFilesystemLoader',
        'hamlpy.template.loaders.HamlPyAppDirectoriesLoader',
      ]
    },
  },
]

Provide simpler syntax for translated text

Or make all plain text optionally translatable?

Putting some translatable text inside a tag (e.g. <b>{% trans "Hello" %}</b>) is a very common pattern but currently requires 2 lines, e.g.

%b
  - trans "Hello"

Would be nice to make this pattern more succinct, or possibly make all plain text optionally translatable? That is...

%b Hello

Would become <b>{% trans "Hello" %}</b> if "auto-i18n" is enabled.

pypy 5.7 doesn't like unicode in import() in template/utils.py

Hey,

I just noticed that our pypy'd celery workers won't start with django-hamlpy under pypy 5.7 for python 2.7.

I removed unicode_literals import as a quickfix, might be a PyPy/future bug.

Traceback (most recent call last):
  File "manage.py", line 49, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/core/management/__init__.py", line 345, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/djcelery/management/commands/celery.py", line 21, in run_from_argv
    ['{0[0]} {0[1]}'.format(argv)] + argv[2:],
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/celery.py", line 793, in execute_from_commandline
    super(CeleryCommand, self).execute_from_commandline(argv)))
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/base.py", line 311, in execute_from_commandline
    return self.handle_argv(self.prog_name, argv[1:])
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/celery.py", line 785, in handle_argv
    return self.execute(command, argv)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/celery.py", line 717, in execute
    ).run_from_argv(self.prog_name, argv[1:], command=argv[0])
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/worker.py", line 179, in run_from_argv
    return self(*args, **options)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/base.py", line 274, in __call__
    ret = self.run(*args, **kwargs)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/bin/worker.py", line 212, in run
    state_db=self.node_format(state_db, hostname), **kwargs
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/worker/__init__.py", line 95, in __init__
    self.app.loader.init_worker()
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/loaders/base.py", line 128, in init_worker
    self.import_default_modules()
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/loaders/base.py", line 116, in import_default_modules
    signals.import_modules.send(sender=self.app)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/utils/dispatch/signal.py", line 166, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/fixups/django.py", line 73, in on_import_modules
    self.worker_fixup.validate_models()
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/celery/fixups/django.py", line 173, in validate_models
    cmd.check()
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/core/management/base.py", line 426, in check
    include_deployment_checks=include_deployment_checks,
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/core/checks/registry.py", line 75, in run_checks
    new_errors = check(app_configs=app_configs)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/admin_tools/checks.py", line 18, in check_admin_tools_configuration
    get_template('admin:admin/base.html')
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/loader.py", line 32, in get_template
    return engine.get_template(template_name, dirs)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/backends/django.py", line 40, in get_template
    return Template(self.engine.get_template(template_name, dirs), self)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 190, in get_template
    template, origin = self.find_template(template_name, dirs)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 153, in find_template
    for loader in self.template_loaders:
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/utils/functional.py", line 33, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 118, in template_loaders
    return self.get_template_loaders(self.loaders)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 123, in get_template_loaders
    loader = self.find_template_loader(template_loader)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 146, in find_template_loader
    return loader_class(*args)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/loaders/cached.py", line 24, in __init__
    self.loaders = engine.get_template_loaders(loaders)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 123, in get_template_loaders
    loader = self.find_template_loader(template_loader)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/template/engine.py", line 136, in find_template_loader
    loader_class = import_string(loader)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/django/utils/module_loading.py", line 20, in import_string
    module = import_module(module_path)
  File "/usr/idb/www/apps/worker4/pypy/pypy/lib-python/2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/hamlpy/template/__init__.py", line 6, in <module>
    from .loaders import haml_loaders as _loaders
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/hamlpy/template/loaders.py", line 68, in <module>
    haml_loaders = dict((name, get_haml_loader(loader)) for (name, loader) in get_django_template_loaders())
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/hamlpy/template/utils.py", line 14, in get_django_template_loaders
    for loader in get_submodules(loaders) if hasattr(loader, 'Loader')]
  File "/usr/idb/www/apps/worker4/envpypy/site-packages/hamlpy/template/utils.py", line 19, in get_submodules
    return [__import__(module, {}, {}, [module.rsplit(".", 1)[-1]]) for module in submodules]
TypeError: 'fromlist' items must be str, not unicode

Implement a proper attribute dictionary parser

We currently use regexes to transform the attribute dictionary into a python dict, and parse it with eval, which is fragile, and loses attribute ordering. We can either try merging https://github.com/jessemiller/HamlPy/tree/element_parser or just salvage what we need from that branch.

Disallow colon prefixes when not using old style Ruby attribute dicts

This is valid:

%span{:class => "test"}

but these should be errors:

%span{:class:"test"}
%span(:class="test")

Add support for HTML style attribute dictionaries

HAML supports two different syntaxes for attribute dictionaries:

%html{"xmlns":"http://www.w3.org/1999/xhtml", "xml:lang":"en", "lang":"en"}

%html(xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en")

The latter one is preferable in several ways - no commas - parentheses can't be confused with Django tags which use {

Highlights filter doesn't guess language correctly

Currently the highlights filter defaults to a Python lexer, using pygments==2.1.3, but the latest pygments==2.2 returns a generic text lexer.

Would be better if there was some way to explicitly select the language. Problem is that Haml filters can't take arguments. Maybe we set a default language as a compiler setting?

Intellij (Pycharm) support

These are some of the gripes I encountered while using this (otherwise Awesome) library inside of pycharm

Pycharm provides support for code completion of django tags only when they're used as actual django template tags, meaning:

This gets code-completed
{% url 'spotify login' %}

But this doesn't
- url 'spotify login'

currently, pycharm doesn't recognize the amazing filters offered by this library.

For example, the :python filter

As you can see, there is no syntax highlighting.

Add :less and :sass filters

Would be nice and convenient instead of having to do:

<style type="text/less">
:plain
  @color: #4D926F;
  #header {
    color: @color;
  }
</style>

Could instead be:

:less
  @color: #4D926F;
  #header {
    color: @color;
  }

PEP 8 Issues

How do we feel about cleaning up some of the many PEP issues and using flake8 as part of the CI build?

Add 1.0 to releases page?

https://github.com/nyaruka/django-hamlpy/releases

Remove support for =# comments

This isn't HAML or Django

Attribute values which are multiline Haml can't have blank lines

For example, this doesn't parse correctly:

%span{
  'class':
    - if forloop.first
      link-first

    - else
      link-last
 }

Add option for extension agnostic loader

In RapidPro we have https://github.com/nyaruka/rapidpro/blob/master/temba/utils/haml.py which will turn foo.haml when requested foo.html. We need this for overriding smartmin .html templates as .haml files.

Could add option to existing loaders to ignore extension on requested template.

Support parentheses style attribute dictionaries

From: http://haml.info/docs/yardoc/file.REFERENCE.html

HAML supports an alternative syntax like:

%a(class="foo bar" id="bar")

I like this MUCH more because:

It uses ='s around key/value pairs just like HTML attributes
It doesn't have commas around key/values just like HTML
It doesn't use {} like Django does, so it is clearer which parts are HAML and which are Django

Compare these two:

%a.btn.btn-primary( style="float:right; margin-left:10px" href="{% url 'orgs.topup_create' %}?org={{ org.id }}" ) Add TopUp

And

%a.btn.btn-primary{ style:"float:right; margin-left:10px", href:"{% url 'orgs.topup_create' %}?org={{ org.id }}" } Add TopUp

Former is a lot nicer in my opinion.

Sort PR from jessemiller repository and see which ones we want to merge

Currently, there are 9 PR that we haven't merged yet, those are:

Added {% hamlpy %} jinja2 tag, with tests and documentation jessemiller#160

I don't use jinja2 with django so I'm not really interested but this doesn't seems very heavy to maintain.

Change regexp search method jessemiller#158 which fixes jessemiller#126

I think that this one is still relevant and could be merged.

[DONE] Add call and macro tags to the self-closing dict jessemiller#155

I've just merged it since it was small and relevant.

Python-style conditional constructs in attribute dictionaries jessemiller#148

I have mixed feelings about this one. I think that this extends haml beyond it's original goal and this patch doesn't work anymore since we have switch of parser behavior. I don't know it it's worth it over {% if condition %}a{% else %}b{% endif %}.

:sass filter for YAML-like CSS styling https://github.com/jessemiller/HamlPy/pull/143/files

I don't uses sass but this one could be neat and looks quite simple.

{% include %} template tags do not work with non-VALID_EXTENSIONS https://github.com/jessemiller/HamlPy/pull/121/files

Again, looks simple and worth it.

added compact notation for dynamic attributes jessemiller#109

I have mixed feelings about this one and I don't think that this work anymore. Also the codegen dependency seems unmaintained now.

web2py support / inline coffeescript tags https://github.com/jessemiller/HamlPy/pull/19/files

I have no opinion about web2py (is it still used?), coffeescript tag seems neat.

No hurry about discussing those nor merging those at all, I just wanted to have them listed somewhere

Text in a %style tag should not be changed

To be more specific, any text in %style tags that use the .class or #id syntax should not be replaced with divs.

:css
  .myclass {
    color: red;
  }

%style(type="text/css")
  .myclass {
    color: red;
  }

Gets converted to

<style type='text/css'>
  .myclass {
    color: red;
  }
</style>

<style type='text/css'>
  <div class='myclass'>{    color: red;
</div>
  }
</style>

This is probably also an issue with %script but I haven't run into it.

Nested comments are rendered

If you have a comment where a child is also a comment, like:

/ %input
  / text

Then it's rendered as:

<!-- 
<!-- text -->
-->

The first closing tag for the comment closes both comments, and you end up with --> being rendered onto the page.

Expected result: Nested comment tags are not rendered

integrate or point to html2hamlpy?

Just to point out this, also unmaintained, repository that could a useful tool for this project
https://github.com/davidtingsu/html2hamlpy

README.md URL to http://www.haml-lang.com/ is dead

[feature request] multi-line django template tags

First of all: Thank you for picking up maintenance of the package! 👍

We just noticed in #583c0a3 with that we can't use multi-line django template tags anymore... which was neat to increase readability. e.g.

{% my_tag
   so=True
   many='VeryLongStringIdWhatever'
   params=somevar
   ...
%}

Any chance in getting this feature back?

Remove support for ={...} substitutions or make it optional

I'm not sure why this was added because it's neither actual HAML or Django. It breaks existing templates where users have used things like {href: "foo={{ bar }}"}.

I'd like to either remove it for a version 1.0 release, or at least make a way to disable it.

Remove convert_files entry point

Better for users to use the watcher script with the --once argument as this script supports all the different compiler options.

Name is also misleading as it only converts a single file.

Add support for plural within blocktrans

For example:

-blocktrans count amount=num_cookies
  There is one cookie
-plural
  There are #{ amount } cookies

Tests depend on deterministic ordering of attributes

django-hamlpy/hamlpy/elements.py

Line 137 in 9224b44

attributes_dict = eval(attribute_dict_string)

evaluates a parsed attribute dictionary as a Python dict, but that means attribute ordering is non-deterministic.

This leads to tests sometimes failing which depend on order, e.g.

django-hamlpy/hamlpy/test/test_elements.py

Line 52 in 37d63ad

eq_(sut.attributes, "a='something' c='2' b")

Question is whether html attribute order should match haml attribute order?

Rename Jinja extension module to jinja

Module is currently called ext which isn't very descriptive

Remove django_inline_style option

Provide testing code for the haml-spec project

https://github.com/haml/haml-spec

And add missing features, e.g. &= syntax

Make all compiler options configurable as Django setting

Instead of a single Django setting per compiler option, just have one which is a dict, i.e.

HAMPLY_OPTIONS = {
  "escape_attrs" : True,
  "format": "xhtml"
}

HTML style attributes can't span multiple lines

Ruby {foo: bar} style attribute dictionaries can span multiple lines but the new HTML style dictionaries added in #29 can't.

Deosn't work with django 1.11b

They seem to have removed templatize from trans_real in the new django beta, which breaks hamlpy

  File "/usr/local/lib/python3.6/site-packages/hamlpy/template/__init__.py", line 4, in <module>
    from . import templatize  # noqa
  File "/usr/local/lib/python3.6/site-packages/hamlpy/template/templatize.py", line 30, in <module>
    trans_real.templatize = decorate_templatize(trans_real.templatize)
AttributeError: module 'django.utils.translation.trans_real' has no attribute 'templatize'

Should support tag names with hyphens

Using several "with" statements on the same block level does not render the closing tag at the correct spot

Copying this from the old repo: jessemiller#170

Example:

- with some_context
  ...
- with some_other_context
  ...

Gets compiled to:

{% with some_context %}
  ...
{% with some_other_context %}
  ...
{% endwith %}
{% endwith %}

Should be:

{% with some_context %}
  ...
{% endwith %}
{% with some_other_context %}
  ...
{% endwith %}

Deprecate support for HAMLPY_DJANGO_INLINE_STYLE

Make the default False

Add :preserve filter

Like :plain but whitespace is converted to HTML entities which preserve it.

See original issue from @davidtingsu at jessemiller#161

django-hamlpy==1.4.2 not compatible with Django==3.1.4

I'm using pip version 20.3.3 (Python 3.7 btw):

$ pip install django-hamlpy==1.4.2 Django==3.1.4
...
ERROR: Cannot install Django==3.1.4 and django-hamlpy==1.4.2 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested Django==3.1.4
    django-hamlpy 1.4.2 depends on django<3.0 and >=2.1

It seems like this issue isn't caught by GitHub CI, due to poetry wrapping the pip install. If you look at a recent CI job, specifically for Django 3.1.4, and expand the "Initialize environment" step, you'll see the same pip error.

Which system libraries are required for this?

Trying to install in docker using the command listed (pip install django-hamlpy) but I get

` error: command 'gcc' failed with exit status 1

----------------------------------------

Command "/usr/local/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-sev5hbgy/regex/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-ix5firn9-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-sev5hbgy/regex/`

Which system libraries or utilities are required to install, and can you update the README to reflect this?

Give an option to make use of markdown extensions if needed

Markdown library allows to use extensions that enhance the markdown syntax adding useful things.

https://python-markdown.github.io/extensions/

An option in Django settings where to list the extensions to use would be very useful.

Stop Indenting the contents in textarea tag

I used textarea tag like below:

%textarea.myclass
    - trans "contents row1"
    - trans "contents row2"

But some indents appeared before each line.

In Ruby haml, this seems a well-known problem and official docs has a guide to avoid it.
http://haml.info/docs/yardoc/file.FAQ.html#how-do-i-stop-haml-from-indenting-the-contents-of-my-pre-and-textarea-tags
But is there's a similar way in django-hamlpy?

Attribute values can't contain braces

Because of the way the compiler determines if an attribute dictionary span multiple lines, by just counting brace characters, i.e. https://github.com/nyaruka/django-hamlpy/blob/master/hamlpy/hamlpy.py#L102

Don't pretty format generated HTML

Until recently the main Ruby Haml implementation supported "ugly" output as an option for production instances where performance is more important than pretty HTML. That has now become the only output mode in this PR haml/haml#894 and the haml-spec project has been updated accordingly https://github.com/haml/haml-spec.