[quote=xwolf,17.09.2005, 17:27]Ein anderer Vorteil ist: Das Ding unterstützt templategesteuerte Datenbankabfragen.
D.h. der Redakteur der ein Template schreibt, kann ohne Perlwissen Operation auf Datenbanken durchführen lassen.[/quote]
Das können andere aber auch. Der Template Toolkit zum Beispiel.

Der Syntax scheint mir noch ein bißchen gar aufwendig, und ich würde weggehen von programmierspezifischen Begriffen wie "print". Eher "get" oder "out" oder etwas in die Richtung.

[quote=xwolf,15.10.2005, 22:48]Gibt es denn keine sonstige Template-Sprache die auch gleichzeitig unter was anderes läuft als nur unter Perl?[/quote]
Oh, doch. Ich habe schon einige HTML-Template ähnliche/kompatible Module z.B. für Ruby oder Python gesehen, aber auch umgekehrt. PeTAL ist die Perl-Version der in Zope/Python verwendeten (Me?)TAL - Template Sprache, die speziell valide XML/(X)HTML Syntax ermöglicht. Eine Templating-Sprache/Engine die jetzt absolut ursprungsunabhängig ist fällt mir nicht ein.

Eine CPAN-Version ist aber für eine breitere Basis im Perl-Bereich unabdingbar. Das Kamel-Volk ist aber was Templating-Engines betrifft mittlerweile sehr gesättigt, so daß du sehr gute Gründe anführen musst, wenn du dein Modul z.B. bei den Monks vorstellst.\n\n

<!--EDIT|Ronnie|1129411243-->

[quote=ptk,16.10.2005, 03:39][quote=xwolf,16.10.2005, 00:24]Von der Codequalität erfüllt es IMHO die Standards für CPAN.[/quote]
Das Modul benötigt noch ein Makefile.PL. Es wird bestimmt nicht gern gesehen, dass der Modulname mit einem kleinen Buchstaben anfängt und auch nicht aus zwei Teilen besteht (e.g. Text::Txtpl).
Du mischt bei den Errorcodes noch deutsche und englische Texte. Die Einrückung ist nicht einheitlich, jedenfalls sieht der Programmtext auf einem normalen Terminal mit Tab=8 Zeichen nicht einheitlich aus.[/quote]
Hu? Die Makefile fehlt ?!
Mist, hast recht, da hat mich der Makemaker veräppelt... Hat der doch die File beim hinzufügen der neuen Files diese weggelassen :(
Ist jetzt in der neuen Version drin.

Namen: Ja, klar. Aber sollte ich es irgendwann ins CPAN reinbringen weiss ich eh nicht ob dann Text::Txtpl nicht doch noch geändert wird. Also lass ich es erstmal damit einen konformen namen zu nehmen. Oder meinst du, Text::Txtpl würde als Name durchgehen?


Bei der Einrückung und der verwendeten Sprache der Meldungen ists eher ein organisatorisches Problem.\n\n

<!--EDIT|xwolf|1129456790-->

Hi,

ich hab gerade eine neue Version meines Textparser-Moduls txtpl online gestellt:
http://www.txtpl.com/download/txtpl-2.07.tar.gz

Ich würde mich freuen, wenn es sich jemand anschauen würde :)

Beispiele zur Nutzung sind in der beigelegten Datei test.pl (welche die Beispieltemplates in samples/ nutzt) zu sehen.

Die Dokumentation im POD-Teil des Modouls ist leider noch etwas sparsam - ich hab gestern abend erst begonnen, es auf englisch umzustellen.
Eine umfangreiche deutschsprachige Doku zur Sprache findet sich bei http://www.txtpl.de unter "Dokumentation".


Ciao,
Wolfgang

Hi,

die Frage hab ich erwartet :)

Der Hauptvorteil besteht darin, daß die Sprache gezielt zu dem Zweck definiert wurde, eine programmiersprachunabhängige Syntax zu haben.
Also das man Templates auf einem System einmal definiert und dann die selben Templates von einem anderen Programm mit einer anderen Programmiersprache dasselbe liefert.

Es gibt auch eine Delphi-Version (leider noch nicht per LGPL erhältlich) und eine PHP-Version ist in Planung.

In einem konkreten Fall haben wir für ein Client-Server-System zunächst einen mit Delphi programmierten WIndowsclient gehabt, der auf die Templates zugriff. Später, wo dann auch noch die Webversion hinzukam, konnten wir exakt dieselben Templates nutzen und mussten uns also nur noch um die Programmlogik kümmern.

Ein anderer Vorteil ist: Das Ding unterstützt templategesteuerte Datenbankabfragen.
D.h. der Redakteur der ein Template schreibt, kann ohne Perlwissen Operation auf Datenbanken durchführen lassen.

Ciao,
Wolfgang

[quote=dominicn,17.09.2005, 17:52][quote=xwolf,17.09.2005, 17:27]Ein anderer Vorteil ist: Das Ding unterstützt templategesteuerte Datenbankabfragen.
D.h. der Redakteur der ein Template schreibt, kann ohne Perlwissen Operation auf Datenbanken durchführen lassen.[/quote][/quote]

Quote

Das können andere aber auch. Der Template Toolkit zum Beispiel.

In der Tat.
Punkt ist aber, daß die definierte Sprache von Template und anderen aus einer anderen Richtung her entwickelt wurde.
Die Sprachsyntax ist dort weniger angepasst an die gewohnte Perl-Notation, wie z.B. bei Template::Toolkit, sondern eher an den Wunsch es noch weiter sprachunabhängiger zu machen.

Gibt es ein Übersetzung der Template-Stylesyntax für andere Programmiersprachenmodule?

Seht es als Paralellentwicklung, die es ist. Template:Toolkit wurde 2000 entwickelt. txtpl davon unabhängig auch (genauer: 1999 noch unter einem anderen Namen "dicte")- es wurde nur bislang nicht unter der LGPL verbreitet, weswegen es auch bislang nicht in Pause hochgelanden wurde.

Soll man es deswegen wegwerfen?

IMHO hat jedes Modul seine Berechtigung. Es wäre nicht das erste mal und wird nicht das letzte mal sein, wo ähnliche Dinge parallel entwickelt werden.

Ciao,
Wolfgang

[quote=Strat,03.10.2005, 19:31]HTML::Template kann z.B. auch die %XXX% - Syntax (vanguard compatibility mode)[/quote]
Ja. Und?

Mein Beitrag behandelt nicht die Frage welche Template-Module besser oder etablierter sind.

xwolf klar ist jeder stolz auf sein kind ich seh ja auch nicht dahin das es schon 1 2 editoren auf der erde gibt

[quote=xwolf,17.09.2005, 17:27]Der Hauptvorteil besteht darin, daß die Sprache gezielt zu dem Zweck definiert wurde, eine programmiersprachunabhängige Syntax zu haben.[/quote]
Was meinst du mit "programmiersprachenunabhängig"? Viele etablierte Templatingsysteme sind ja auch programmiersprachenunabhängig, z.B. alle die
hier mit "Mini-Language" aufgeführt sind.