Das deutsche Python-Forum

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?!?!?

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

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

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.

Man beachte dies hier:

Armin hat geschrieben: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.

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?

Gutes Argument jens. Das war mein erster Gedanke.

jens hat geschrieben: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.

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?

jens hat geschrieben: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.

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.

blackbird hat geschrieben:
jens hat geschrieben: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

wollte nur mal darauf hinweisen:

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

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

MfG EnTeQuAk

blackbird hat geschrieben: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.

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.

Wie ich nun gesehen hab, ist die Template Engine von django der syntax von jinja sehr ähnlich.

Wozu dann überhaupt noch ein eigenes Template-Projekt? Bzw. warum wurde überhaupt jinja programmiert? Gab es damals die django Template-Engine noch nicht?

Wo liegen die Unterschiede zwischen jinja und dem django Ding?

jens hat geschrieben:Wozu dann überhaupt noch ein eigenes Template-Projekt? Bzw. warum wurde überhaupt jinja programmiert? Gab es damals die django Template-Engine noch nicht?

django templating lässt sich ohne django nicht verwenden. Das war der Punkt.

Ah, das ist natürlich dumm... Schade, andere Komponenten kann man ohne den Rest benutzten...

jens hat geschrieben:Ah, das ist natürlich dumm... Schade, andere Komponenten kann man ohne den Rest benutzten...

Klar kann man es separat auch verwenden. So wie hier mit CherryPy. Man braucht nur eben den ganzen anderenn Django-Kram, auch wenn man ihn nicht nutzen will. Vielleicht kann man mit den Django-Developern reden, dass man die Engine mit weniger Problemen ohne Django verwenden kann.

Leonidas hat geschrieben:
jens hat geschrieben:Ah, das ist natürlich dumm... Schade, andere Komponenten kann man ohne den Rest benutzten...
Klar kann man es separat auch verwenden. So wie hier mit CherryPy. Man braucht nur eben den ganzen anderenn Django-Kram, auch wenn man ihn nicht nutzen will. Vielleicht kann man mit den Django-Developern reden, dass man die Engine mit weniger Problemen ohne Django verwenden kann.

Oder man wartet einfach auf Jinja 1. Das wird sich dann sogar in Django lohnen

Das deutsche Python-Forum

Das aus für Jinja???

Das aus für Jinja???