Schon weil dann die Kompatibilität extrem schrumpfen würde... denn in Jinja 1 ist ja nun einiges anders, als in Django, wenn ich das richtig bemerkt habe oder?
Und ohne eine Hundertprozentige (oder nahezu) Rückwertskompatibilität denke ich, werden die solche Änderungen nicht einfügen... dafür ist Django seit zu langer Zeit recht stabil und wird zu gut und oft genutzt, als das sie durch eine solche Änderung etliche Leute verärgern könnten (vor allem, da empfohlen wird, die jeweils letzte SVN Version zu nutzen )
MfG EnTeQuAk
Jinja 1
*meld*
sind wir schon zwei... und sicherlich noch einige mehr hier im Forum.
Aber das steht hier nun wirklich nicht zur debatte
Back To Jinja
Gibet schon nen Plan, wann Jinja 1 "offiziell" rauskommen wird?
Und wie schauts mit der Umstellung von 'pocoo' aus? -- -- wirds gleich dannach umgestellt oder erst nach dem 0.2dev Release?
MfG EnTeQuAk
sind wir schon zwei... und sicherlich noch einige mehr hier im Forum.
Aber das steht hier nun wirklich nicht zur debatte
Back To Jinja
Gibet schon nen Plan, wann Jinja 1 "offiziell" rauskommen wird?
Und wie schauts mit der Umstellung von 'pocoo' aus? -- -- wirds gleich dannach umgestellt oder erst nach dem 0.2dev Release?
MfG EnTeQuAk
Mach mindestens drei daraus. Und diesen Geschwindigkeitswahn bei Templatesystemen kann ich auch nicht so recht verstehen. Kann mir nur schwer Vorstellen, dass die Zeit im Vergleich zur Datenübetragung und Datenbankabfrage so stark ins Gewicht fällt.
Mit Templatesystemen ist es ja noch schlimmer als mit Webframeworks. Jeder will anscheinend sein eigenes haben.
Mit Templatesystemen ist es ja noch schlimmer als mit Webframeworks. Jeder will anscheinend sein eigenes haben.
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Also wenn pocoo 0.2 Sekunden im Template verscheißt ist das verdammt schlecht. Ohne Grund wurde Jinja nicht neu geschriebenBlackJack hat geschrieben:Mach mindestens drei daraus. Und diesen Geschwindigkeitswahn bei Templatesystemen kann ich auch nicht so recht verstehen. Kann mir nur schwer Vorstellen, dass die Zeit im Vergleich zur Datenübetragung und Datenbankabfrage so stark ins Gewicht fällt.
Weder das eine noch das andere stört mich. Hab ich schonmal WSGI erwähnt?Mit Templatesystemen ist es ja noch schlimmer als mit Webframeworks. Jeder will anscheinend sein eigenes haben.
TUFKAB – the user formerly known as blackbird
Ich sage mal so... Solange eine "neuerfindung" gerechtfertigt ist gibt es keinerlei Probleme... bei Colubrid oder Jinja ist das in meinen Augen gerechtfertigt, da sie gute Verwendung in pocoo haben und Jinja nebenbei eine standalone-Variante der Django-Templates ist/warMit Templatesystemen ist es ja noch schlimmer als mit Webframeworks. Jeder will anscheinend sein eigenes haben.
MfG EnTeQuAk
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Am schluss heißt es "nehmt Buffet oder Turbo*". Aber das hat auch Nachteile, wenn jede TG-App ein anderes Templatesystem nutzt.BlackJack hat geschrieben:Mit Templatesystemen ist es ja noch schlimmer als mit Webframeworks. Jeder will anscheinend sein eigenes haben.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Auf das mit dem gernellen template interface gehe ich jetzt nicht näher ein, aber es gibt jetzt zumindest noch ein Update betreffend Jinja
Seit dem letzten Update gibts doch ein paar neue Sachen:
Seit dem letzten Update gibts doch ein paar neue Sachen:
- Verbessertes Escaping durch Hinzufügen der {% raw %} Direktive. Jetzt kann man auch Jinja Code in Jinja Code haben ohne auf Hilfkonstrukte wie {{ "{{ mein jinja code hier }}" }} zurückgreifen zu müssen.
- Mit debug() bekommt man den aktuellen Template Context ins Template
- range() wurde hinzugefügt mit einem Schutz gegen zu große Listen
- Einige neue Filter
- i18n wird jetzt direkt in Jinja behandelt und zwar auf eine Weise, wie man es tatsächlich einfach in das eigene Programm einbinden kann ohne beschränkt zu werden (nicht so wie bei formencode ^^)
- Fehler in der Inheritance wurden behoben
- Jede Menge unittests
- Drei Neue Loader: ein Loader, der Templates via setuptools aus Python Packages laden kann, ein Loader der mehrere Loader durchprobiert und einer, der Templates aus einem Dict läd
- {% set %} und {% macros %} haben jetzt eine semantische Sonderbehandlung: Sie werden auch definiert wenn sie außerhalb sichtbarer Blöcks sind. Damit lassen sich jetzt ein paar praktische Dinge basteln
- Die unbenutzen Python Keywords wie "def", "class", "import" und co sind nun gültige Bezeichner
- diverse API Änderungen, die es einfacher machen, eigene Loader zu basteln.
- Deferred objects: Objekte die bei Zugriff erst aufgelöst werden. Brauchbar für globale Objekte die aus Datenbanken kommen und nicht immer benötigt werden.
TUFKAB – the user formerly known as blackbird