orfon / reinhardt Goto Github PK

• strings.capfirst, strings.lower, strings.upper - These do not take care of locale-sensitive character capitalization rules for Turkish, Serbian, Croatian, etc.
• strings.truncatechars - This is not sensitive to Unicode surrogate characters or combining characters, and therefore may truncate in the middle of a character. This is particularly troublesome in writing systems that rely heavily on combining characters such as Thai or most of the Indic writing systems like Devanagari, Kannada, Tamil, etc.

templates with string escaping do not work:

        basic-syntax26': ['{{ "\"fred\"" }}', {}, "\"fred\""],
        {{ ""|add:"simon" }}`

another thing which doesnt work but which i dont plan on addinɡ too soon: translation strings

 __("translation string")__ 

filterexpression regex

• our regex https://github.com/oberhamsi/reinhardt/blob/master/lib/filterexpression.js#L35
• django regex https://github.com/django/django/blob/master/django/template/base.py#L484

configuring a template loader is very verbose and akward (see example) and adding custom filters/tags per "project" is impossible.

investigate how jinj2 "Envinronments" solve this problem: http://jinja.pocoo.org/docs/api/#jinja2.Environment

they too are standalone and can't rely on "settings.py" and a project folder, like django does.

django/django@ec371ac

currently it's a mess of lowercamelCase under_score and sometimes just words bashed together ("capfirst").

i think we should go all camelCase before 1.0

django has three functions: simpleTag, assignmentTag and inclusionTag, which take a function as an argument, which they use to create a complete Tag class. Basically those three functions relieve you subclassing the Tag class for specific but common use cases. you only need to write the render function and all the rest - parameter parsing, variable resolving with filter support as well as all interaction with the template parser - is handled automatically.

the three use cases support by django are:

• ease the creation of tags setting a variable in the context
  https://docs.djangoproject.com/en/1.6/howto/custom-template-tags/#assignment-tags
• Many template tags take a number of arguments – strings or template
  variables – and return a string after doing some processing based solely
  on the input arguments and some external information. the SimpleTag helps
  with creating those:
  https://docs.djangoproject.com/en/1.6/howto/custom-template-tags/#howto-custom-template-tags-simple-tags
• displays some data by rendering another template
  https://docs.djangoproject.com/en/1.6/howto/custom-template-tags/#howto-custom-template-tags-inclusion-tags

I have implemented the SimpleTag and - I think - all helpers required to
implement the other Tags.

unit tests in my branch:
https://github.com/oberhamsi/reinhardt/blob/tag-filter-helpers/test/library/tags.js

A problem I noticed is that in JavaScript we can't support an indefinite number of arguments because I can't detect rest parameters in the function signature yet https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/rest_parameters This means we have to think of a different way to support an unknown number of arguments. Just parsing the function signature isn't going to get us there.

django/django@f13bfbe

The filters: ... and tags: ... properties are not documented here:
https://github.com/orfon/reinhardt/blob/master/docs/custom-template-filters.md

It's not clear how to enable custom filters.

django/django@636c45f

• dates and date/time formatting does not use locale-sensitive formats, although it does allow custom date format templates if you happen to know the right template for each and every locale your app needs to support.
• arrays.sortByKey - only sorts with English rules
• logic.yesno - defaults to English stringscapitalization rules for Turkish, Serbian, Croatian, etc.
• strings.title - Only uses English title case rules for deciding which words to capitalize, and does it not do locale-sensitive upper-casing
• strings.floatformat - Only formats numbers with English conventions
• strings.ljust - Only left-justifies strings, which might not work correctly in right-to-left languages like Arabic or Hebrew
• strings.truncatewords, strings.wordcount, strings.wordwrap - Does not work correctly in languages that are not written with whitespaces between every word, such as Chinese, Japanese, or Thai.

this bug collects all commits we should/could port from django

as of 14/3:

improve {% include %} .. support recursion among other things
django/django@e2f0622

widthratio: Inf/Nan
django/django@07ae47f

widthratio: allow "as" param
django/django@ff41056

Fix #20745: Don't silence TypeError raised inside templates.
django/django@28a5713

simplify filterExpression.args_check
django/django@7c6f2dd

Fixed #7557 -- Added type checking to Variable initialization.
django/django@7fec5a2

cache missing templates
django/django@b785a80

At the moment it renders three dots and not a horizontal ellipse …

Some applications (like on Google App Engine) have to use java.util.Date to store dates. At the moment the following code will not work without a prior conversion of story.created into a JavaScript Date object:

{{ story.created | date:"dd.MM.yyyy" }}

there is no way to specify the encoding when loading templates. it defaults to utf8.

a RequestContext takes the request as the first argument and automatically populates the Context with a few variables according to the TEMPLATE_CONTEXT_PROCESSORS

this is how they get things like user, permissions, mediaUrl/staticUrl, messages and csrf protection into their templates.

see:

• https://docs.djangoproject.com/en/1.6/ref/templates/api/#subclassing-context-requestcontext
• https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-TEMPLATE_CONTEXT_PROCESSORS

url tag only makes sense if a routing framework is used to generate URLs.

stick supports url resolving https://github.com/ringo/stick/blob/master/lib/helpers.js#L44

urlFor(app, {action: "edit", id: 5})
urlFor("index", {do: "search"})

only set to "INVALID" if debug=true

django/django@f49e9a5