Das aus für Jinja???

[jens]

Hossa, was muß ich da lesen: http://www.pocoo.org/blog/happy-new-year/
Da hab ich ja auf das richtige Pferd gesetzt

Ich dachte jinja kann auch Templates compilieren?!?!?

[EnTeQuAk]

We haven't decided what we will use in future for templating but support for Jinja won't stop. I'm looking forward to write a new implementation of Jinja especially for sandboxing purposes with a much simpler codebase.

Heißt für mich soviel wie.... Jinja wird weiter existieren... also kannst du das ruhig weiter nutzen.

Wäre allerdings schön, wenn nicht gleich wieder ne neue TemplateEnigne entsteht, sondern Jinja "einfach nur" umgeschrieben wird...


MfG EnTeQuAk

[rafael]

Ich werde mir demnächst auch mal Genshi anschauen... das soll auch ganz interessant sein. Aber Jinja wirds glaube ich weiter geben, weils für kleine Seiten den Zweck ja voll und ganz erfüllt

[Leonidas]

Blackbird hat zu mir gemeint, dass er an einer Art Jinja 2 arbeitet und dass er Ruty als Prototyp dafür verwendet. Von dem her: keine Sorge.

Und wegen Genshi: ist nett für XML, aber für Texttemplates kann es mit Jinja oder Djangos Templates nicht mithalten. AUßer es ist in letzter Zeit sehr viel besser geworden.

[mitsuhiko]

Man beachte dies hier:

We haven't decided what we will use in future for templating but support for Jinja won't stop. I'm looking forward to write a new implementation of Jinja especially for sandboxing purposes with a much simpler codebase.

[jens]

Das hab ich auch gelesen, aber ich wollte zum einen ein wenig aufschrecken Anderer Seits denke ich mir: Wenn ihr in pocoo kein jinja einsetzt, könnte jinja mit der Zeit verstauben.
Warum solltet ihr da Energie rein stecken, wenn ihr eh was anderes nimmt, was besser ist?

Oder bleibt ihr dennoch erstmal bei jinja?

[sape]

Gutes Argument jens. Das war mein erster Gedanke.

[mitsuhiko]

Das hab ich auch gelesen, aber ich wollte zum einen ein wenig aufschrecken Anderer Seits denke ich mir: Wenn ihr in pocoo kein jinja einsetzt, könnte jinja mit der Zeit verstauben.

Wird es nicht.

Warum solltet ihr da Energie rein stecken, wenn ihr eh was anderes nimmt, was besser ist?

Es gibt genug Situationen wo du Sandboxed Template Engines brauchst/haben willst. Für pocoo sieht es aber so aus als wäre das der falsche Schritt. Mit Mako kann keine Template Engine der Welt in Sachen Geschwindigkeit mithalten. Nur gibt es da eben keine Sandbox.

[jens]

Du meinst http://www.makotemplates.org/ ?
Auf der ersten Seite sind Benchmark Werte:

Code: Alles auswählen

Mako:	0.90 ms	    	Myghty:	5.25 ms
Cheetah:	0.70 ms		Genshi:	12.53 ms
Django:	5.43 ms		Kid:	19.12 ms

Demnach ist Cheetah schneller?

Was mir direkt auf der ersten Seite übel aufstößt ist die Syntax:

Code: Alles auswählen

<%inherit file="base.html"/>
<%
    rows = [[v for v in range(0,10)] for row in range(0,10)]
%>
<table>
    % for row in rows:
        ${makerow(row)}
    % endfor
</table>
   
<%def name="makerow(row)">
    <tr>
    % for name in row:
        <td>${name}</td>\
    % endfor
    </tr>
</%def>

Das sieht IMHO krank aus Kein vergleich zu der Klarheit von jinja...
Ich dachte auch immer, das man möglichst wenig Logik in ein Template packen sollte. Das sehen die aber ganz anders, was?

[mitsuhiko]

Du meinst http://www.makotemplates.org/ ?
Auf der ersten Seite sind Benchmark Werte:

Code: Alles auswählen

Mako:	0.90 ms	    	Myghty:	5.25 ms
Cheetah:	0.70 ms		Genshi:	12.53 ms
Django:	5.43 ms		Kid:	19.12 ms

Demnach ist Cheetah schneller?

Cheetah hat einen C Parser. Mako ist reines Python. Zudem kann Mako Inheritance.

Was mir direkt auf der ersten Seite übel aufstößt ist die Syntax:

Damit muss man leben. Ganz so schlimm ist es auch nicht.

Ich dachte auch immer, das man möglichst wenig Logik in ein Template packen sollte. Das sehen die aber ganz anders, was?

Sollte man auch. Daran wird Mako nichts ändern.

[jens]

So ganz verstehe ich das mit dem Sandboxed noch nicht.
Wenn eine Template Engine aus dem Template, echten Python Code erzeugt, ist es nicht Sandboxed? Jinja erzeugt kein Python code, sondern füllt einfach das Template aus. Also arbeitet jinja Sandboxed?

Ist das so richtig?

Ich dachte immer jinja könnte aber auch Templates compilieren und dann wären die super schnell. Ist es aber nicht, weil nur das erneute Parsen wegfällt?

Habt ihr mal wirklich einen Benchmark gemacht? Wie sehen die Werte aus?


In meinem alten "Template gesucht" Thread: http://www.python-forum.de/topic-4231.html hatte ich ja SpyTee gefunden und daraus SpyTee2 gepatcht. Das hat im Grunde auch Python-Code generiert. Ist es also das selbe was Mako macht? Wobei SpyTee keine Inheritance kann.

[sape]

Das hab ich auch gelesen, aber ich wollte zum einen ein wenig aufschrecken Anderer Seits denke ich mir: Wenn ihr in pocoo kein jinja einsetzt, könnte jinja mit der Zeit verstauben.

Wird es nicht.

Großartig

lg

[EnTeQuAk]

wollte nur mal darauf hinweisen:

http://pocoo.org/blog/about-jinja/


Danke an blackbird für diesen ausführlichen Blog-Post!

MfG EnTeQuAk

[jens]

Es gibt genug Situationen wo du Sandboxed Template Engines brauchst/haben willst. Für pocoo sieht es aber so aus als wäre das der falsche Schritt. Mit Mako kann keine Template Engine der Welt in Sachen Geschwindigkeit mithalten. Nur gibt es da eben keine Sandbox.

Wie siehst denn nun aus? Was macht ihr in pocoo?

Setzt ihr weiterhin auf jinja und verbessert es parallel.
Ich meine, die Implementation ist ja eigentlich unabhängig von der verwendeten Template Syntax und die ist bei jinja doch ziemlich gut.

[mitsuhiko]

Wie ich bereits gesagt habe: Die Entwicklung von Jinja läuft unabhängig von pocoo. Ob Jinja 1.0 dann in pocoo wirklich verwendet wird hängt in erster Linie von der Tatsächlichen Performance und dem Willen der Template Designer ab. Und das ist momentan hauptsächlich beewee.