CGI, SSI, und HTML::Template

[myMojito]

Hallo SelfForum,

ich realisieren meine Internet-Projekte immer mit Perl in Verbindung mit dem Modul HTML::Template.

Manchmal komme ich jedoch an Probleme, die ich mit den bisherigen Mitteln nicht lösen kann. Dies ist der Fall, wenn z.B. eine aktuelle Nachricht aus der Datenbank in jeder Seite des Projektes eingebunden werden soll. Bisher habe ich in jedem Template, und dem dazugehörigen Perl-Skript, die Daten ausgelesen und dargestellt. Diese Lösung finde ich jedoch etwas umständlich.

In PHP finde ich oft die nette Lösung, das ein Skript per include in das HTML-Dokument eingebunden wird, und somit immer nur ein Script für die Darstellung der aktuellen Nachricht zuständig ist. Gibt es unter Perl in Verbindung mit dem Modul HTML::Template ähnliche Möglichkeiten? Ich habe da mal an SSI gedacht... ist das eine Lösung die ich nehmen könnte, oder gehe ich da einen falschen Weg?

Bin für jeden Lösungsvorschlag dankbar.

greets
myMojito

[xwolf]

Hi,

Gibt es unter Perl in Verbindung mit dem Modul HTML::Template ähnliche Möglichkeiten? Ich habe da mal an SSI gedacht... ist das eine Lösung die ich nehmen könnte, oder gehe ich da einen falschen Weg?

Jaaa....

ich hab dafür einen eigenen Textparser geschrieben, der stark auf Datenbank-Ausgaben ausgerichtet ist.
Also z.B. dass du innerhalb eines Templates diverse SQL-Queries hast und dessen Ergebnisse wiederum mit IF-Bedingungen und untertemplates ausgeben kannst.

Siehe: http://dicte.xwolf.de/cvs-tree/dicte/perl/v1/
Doku: http://dicte.xwolf.de/cvs-tree/dicte/doc/dicte1.pdf

Sonstiges: http://dicte.xwolf.de/cvs-tree/dicte/

Derzeit bin ich am Erstellen der Version 2, bei der die Tags etwas besser strukturiert  sind und die IF-Bedingungen etwas besser funktionieren.
(Ausserdem wird das ganze dann einen anderen Namen bekommen)

Ciao,
  Wolfgang

[myMojito]

Hallo Wolfgang,

deine Lösung hört sich sehr gut an, doch das ganze betrachte ich mit einem lachenden und einem weinenden Auge...

Ich habe mich schon sehr an das Arbeiten mit HTML::Template gewöhnt. Dein Parser ist natürlich viel Mächtiger, aber für mich würde es wieder umdenken und einarbeiten bedeuten. Mal sehen, ob ich mir das antue ;-)

Was spricht eigentlich gegen eine SSI Lösung? Performace? Ich kann mir nur vorstellen, das zwischen Webserver und Perl-Compiler mehr "Datenverkehr" stattfindet, ob sich das aber für den Anwender auswirkt?

Wenn ich aber mehr Zeit und Muse habe, werde ich mir dein Parser gerne zur Brust nehmen... vielleicht brauchst Du ja noch einen "Beta?"-Tester.

greets
myMojito

[xwolf]

Hi

Ich habe mich schon sehr an das Arbeiten mit HTML::Template gewöhnt. Dein Parser ist natürlich viel Mächtiger, aber für mich würde es wieder umdenken und einarbeiten bedeuten. Mal sehen, ob ich mir das antue ;-)

Dann warte lieber auf die Version 2 :)
Da benutz ich dann "anstaendige" Tags und es ist alles viel logischer und strukturierter...

Was spricht eigentlich gegen eine SSI Lösung? Performace? Ich kann mir nur vorstellen, das zwischen Webserver und Perl-Compiler mehr "Datenverkehr" stattfindet, ob sich das aber für den Anwender auswirkt?

SSI funktioniert so:

Webserver ruft SSI-Parser auf. SSI-Parser entdeckt CGI-Include
und ruft deswegen dann den Wrapper auf, der das CGI ausfuehrt.
Die Ausgaben gehen dann zurueck an den SSI-Parser, damit der weitermachen kann (es kann ja noch Rekursionen geben).
Erst wenn keine SSI-tags mehr da sind, geht es zum Webserver.
Der Webserver gibt es dann an den User.

Also im Prinzip ist es ein Schritt mehr dazwischen.

Aber... ich wuerde soweit es geht, auch immer SSI nehmen.

Mein parser ist deswegen als CGI gemacht, weil der auch andere Zwecke hat als nur Web.
Es gibt naemlich auch eine Delphi-variante, mit der man mit Hilfe der selben Templates die Ausgaben als Windows-Client ausgeben kann.

Oder man baut mit den Parser Mails zusammen...

Wenn ich aber mehr Zeit und Muse habe, werde ich mir dein Parser gerne zur Brust nehmen... vielleicht brauchst Du ja noch einen "Beta?"-Tester.

Jo :=)

Ciao,
  Wolfgang

[myMojito]

Hallo Wolfgang,

Dann warte lieber auf die Version 2 :)
Da benutz ich dann "anstaendige" Tags und es ist alles viel logischer und strukturierter...

Gut, werde ich machen.. solange arbeite ich noch an meinem geliebten HTML::Template ;-)

SSI funktioniert so:

Webserver ruft SSI-Parser auf. SSI-Parser entdeckt CGI-Include
und ruft deswegen dann den Wrapper auf, der das CGI ausfuehrt.
Die Ausgaben gehen dann zurueck an den SSI-Parser, damit der weitermachen kann (es kann ja noch Rekursionen geben).
Erst wenn keine SSI-tags mehr da sind, geht es zum Webserver.
Der Webserver gibt es dann an den User.

Also im Prinzip ist es ein Schritt mehr dazwischen.

Aber... ich wuerde soweit es geht, auch immer SSI nehmen.

Okay, danke für die ausführliche Erläuterung, dann versuche ich mich mal mit SSI! Freu' mich schon auf deine 2. Version des Parsers...

greets
myMojito

[Michael Schröpl]

Hi myMojito,

ich realisieren meine Internet-Projekte immer mit Perl in Verbindung mit dem Modul HTML::Template.
Manchmal komme ich jedoch an Probleme, die ich mit den bisherigen Mitteln nicht lösen kann. Dies ist der Fall, wenn z.B. eine aktuelle Nachricht aus der Datenbank in jeder Seite des Projektes eingebunden werden soll. Bisher habe ich in jedem Template, und dem dazugehörigen Perl-Skript, die Daten ausgelesen und dargestellt. Diese Lösung finde ich jedoch etwas umständlich.

warum hast Du diese Funktion nicht in ein Modul ausgelagert, welches von all Deinen Skripten "use"d wird?

Deine objektorientiert klingende Modellierungsstruktur ist der richtige Weg - und Perl unterstützt die entsprechende Code-Organisation auch hinreichend gut.
Löse Dich vom Begriff des Skripts - denke in modularen Programmen. Verwende Deine eigenen Module exakt so, wie Du HTML::Template verwendest. Trenne Deine Anwendung in eine Datenzugriffsschicht (Module mit Ausrichtung auf hohe Wiederverwendbarkeit) und eine Visualisierungsschicht (CGI-Skripte, deutlich näher am konkreten Einsatzfall) - und Dein Problem verschwindet von alleine.

Bin für jeden Lösungsvorschlag dankbar.

Ich halte die Verwendung von SSI/CGI und den Start zusätzlicher Prozesse für heftig oversized.
Deine bisherige Struktur ist wesentlich performanter (zumal SSI ja nicht gerade der Renner im Apache-Stall ist - dazu kann es viel zuviel).

Viele Grüße
      Michael

[myMojito]

Hallo Michael,

warum hast Du diese Funktion nicht in ein Modul ausgelagert, welches von all Deinen Skripten "use"d wird?

Deine objektorientiert klingende Modellierungsstruktur ist der richtige Weg - und Perl unterstützt die entsprechende Code-Organisation auch hinreichend gut.
Löse Dich vom Begriff des Skripts - denke in modularen Programmen. Verwende Deine eigenen Module exakt so, wie Du HTML::Template verwendest. Trenne Deine Anwendung in eine Datenzugriffsschicht (Module mit Ausrichtung auf hohe Wiederverwendbarkeit) und eine Visualisierungsschicht (CGI-Skripte, deutlich näher am konkreten Einsatzfall) - und Dein Problem verschwindet von alleine.

Dein Ansatzpunkt überzeugt, und ich werde auch mal in dieser Richtung weiterdenken... Mein Knackpunkt war seither immer der folgende: Ich Lagere die komplette Funktionalität der "Nachrichten-Übersicht" in einem Modul aus, welches die darstellbaren Inhalte als Variable zurück gibt. Diese Varbialen übergebe ich mittels dem HTML::Template-Modul an meine HTML-Vorlage.
Ändert sich jetzt die Datenstruktur. muss ich das Modul, mein Skript und die Vorlagen anpassen (wobei ich auch mit HTML::Template HTML-Schnippsel includen kann). Da finde ich die PHP-änhliche Lösung, in der man in eine HTML-Datei ein PHP-Skript includet, das die gewünschte Aufgabe übernimmt ein wenig übersichtlicher, und wollte dies mit SSI nachbilden.

Ich halte die Verwendung von SSI/CGI und den Start zusätzlicher Prozesse für heftig oversized.
Deine bisherige Struktur ist wesentlich performanter (zumal SSI ja nicht gerade der Renner im Apache-Stall ist - dazu kann es viel zuviel).

Genau deshalb wollte ich hier nochmals nachhaken um die Erfahrungen von anderen Forum-Teilnehmern aufgreifen zu können. Mir ist bewusst, das ich mit dem großen Bruder "CGI" arbeite, und plötzlich auf den kleinen Bruder "SSI" ausweiche, obwohl ich mit reinen Bordmitteln schon alles abdecken könnte.
Ich muss glaube ich einfach mal eine Lösung erstellen, um mir den Vor- und Nachteilen bewusst zu werden.

greets
myMojito

[Michael Schröpl]

Hi myMojito,

Mein Knackpunkt war seither immer der folgende: Ich Lagere die komplette Funktionalität der "Nachrichten-Übersicht" in einem Modul aus, welches die darstellbaren Inhalte als Variable zurück gibt. Diese Varbialen übergebe ich mittels dem HTML::Template-Modul an meine HTML-Vorlage.

Daran mußt Du nichts ändern - nur bekommt die Struktur oberhalb von HTML::Template selbst wiederum mehrere Schichten.

Ändert sich jetzt die Datenstruktur. muss ich das Modul, mein Skript und die Vorlagen anpassen (wobei ich auch mit HTML::Template HTML-Schnippsel includen kann).

Nicht, wenn alle Aufrufe der obersten Schicht durch einen Modul der Zwischenschicht laufen und die Parametrisierung hinreichend flexibel ist. (Wenn Du Angst davor hast, ständig Parameterlisten anzupassen, dann übergib Hashes als Parameter oder baue die Zwischenschicht objektorientiert.)
Der Trick ist, daß die Kante zu HTML::Template möglichst "dünn" wird - dann hast Du die minimale Anzahl von Anpassungsstellen zu pflegen. (Beispielsweise auch dann, wenn eine neuere Version von HTML::Template plötzlich anders funktionieren würde - sie könnte ja beispielsweise plötzlich mehr können ...)

Mir ist bewusst, das ich mit dem großen Bruder "CGI" arbeite, und plötzlich auf den kleinen Bruder "SSI" ausweiche, obwohl ich mit reinen Bordmitteln schon alles abdecken könnte.

Ja, auch - aber vor allem arbeitest Du bei SSI mit dem großen Bruder "HTTP-Request", während es bei CGI der kleine Bruder "Perl-Funktionsaufruf" auch schon tut.
Das ist der große Performance-Unterschied - die Roundtrips innerhalb des Apache.

Viele Grüße
      Michael

[myMojito]

Hallo Michael,

vielen Dank für deine hilfreichen Denkanstöße.
Ich habe mit meiner Frage nicht die Absicht gehabt vorgefertigten Perl-Code vor den Latz geknallt zu bekommen.
Meine Absicht war es, meine Arbeitsweise auf Schwächen zu testen und einen kleinen EInblick in die Arbeitsweise Anderer zu bekommen.
Da hat mir deine Art zu Antworten sehr gut gefallen.

Ich wünschte mir mehr Threads wie diesen, und nicht das Tägliche:

Frage: Ich hab von Nichts ne Ahnung, will aber Alles machen.
Antwort: Les erst mal die FAQ und stelle deine Frage richtig.

In diesem Sinne...
viel Spaß und Erfolg bei all deinen Projekten.

greets
myMojito

[Michael Schröpl]

Hi myMojito,

Da hat mir deine Art zu Antworten sehr gut gefallen.

mir Deine Frage genauso.

Ich wünschte mir mehr Threads wie diesen

Ich auch. :-)

viel Spaß und Erfolg bei all deinen Projekten.

Danke, gleichfalls!

Viele Grüße
      Michael