On Sat, Aug 28, 2010 at 11:47 AM, Gabriele Fantini
<gabriele.fant...@gmail.com> wrote:
> Hi,
>
> I've just joined this group. The reason is that I've recently
> developed a new django template system (and I'm still working on it)
> and I'm currently using it for my new sites.
> I hope this is the right place to discuss of such things.
>
> This is the basic idea of my templates:
>
> * The Template class turned into a Python code generator
> * The compilation of a template string (Template.compile_string
> method) consists in the generation of python code that when will be
> evaluated will generate the html source.
>
> Basic steps of the algorithm are:
> * When a template rendering is required, a new Template instance is created.
> * The __init__ method generates a python code, compiles it using
> compiler.compile (python compiled module) and stores the result in a
> class attribute `__compiled` (the standard Template class instead
> generates and store the nodelist)
> * As the rendering is requested the previously compiled python
> code is evaluated using builtin function `eval`, passing context as
> "globals" environment ( eval(compiled, context) ).
>
> Pros of this solution:
> * The implementation is clear and short; 250 lines of code do the magic
> All the statements are exactly the python statements
>
> * Python code and HTML/CSS/Javascript can be mixed together
>
> * No more need to extend with tags and filters; you can use all that
> python provides and extend with modules.
> You can do things like:
> 1) for statement example:
> {% for i in [1, 2, 3] %} <label>{{i}}</label>{% end %}
>
> 2)
> {% for k, v in {'a': 1, 'b': 2} %}
> <label>{{k}}</label> <label>{{v}}</label>
> {% end %}
>
> 3) import a module and use it
> {% import datetime%}
> {{ datetime.datetime.utcnow().isoformat() }}
>
> 4) define functions (and classes) and use it
> {% def myfunction(arg) %}
> return arg.lower()
> {% end %}
> {{ myfunction("TEST STRING") }}
>
> * The only things that were missing were the django specific
> statements (extends, block, ...)
>
> * A new "block" type called "fblock" as been introduced; it is like a
> block that can have arguments.
>
> Well, this is in brief the idea, it can do much more.
> I hope I explained it clearly.
> You can find attached the patch from the latest version 1.2.1 and also
> a test site that shows the power of this solution.
>
> The patch also include:
> 1) A bug fix for the makemessages: code syntax for the xgettext was
> Perl instead of Python
> 2) A compiled template cache
> 3) A few lines changes in order to obtain the exception class in the
> 500 error handler (so that the 500 page message can be exception
> dependent)
>
> If you find this interesting we can work to include it in the django
> repository as an alternative from the current template system.
> Otherwise I'll keep it for my own use.
> The template syntax has a few changes but the backward compatibility
> can be improved.
> If someone wants to try it and have problems or questions I'll be glad
> to answer to any question.
> I can send an already patched version if someone want it.
>
> Hope to have feedback soon,
> Gabriele
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
With all due respect: no. The template system is intentionally not
Python, this is a strong design decision and I see no compelling
argument against it here. If you're just generally interested in the
compilation of Django templates to PYthon (without changing the
current semantics) I suggest you take a look at :
http://www.mail-archive.com/django-developers@googlegroups.com/msg25147.html,
which was a GSOC proposal I wrote (and ultimately withdrew in favor of
my query-refactor work), it presents a method for translation of
Django templates into Python code, while maintaing the current
semantics.
As a small sidenote, when proposing a change a patch should contain a
single change, rather than a number of unrelated ones.
Thanks,
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
