Stefan Beyer: SSI in CGI?

Kann es sein, dass das nicht möglich ist? Bei mir gibt er nicht einmal eine Fehlermeldung aus und behält die Includes im Quellcode.

Gruß Stefan

  1. hi,
    mit dem problem habe ich mich auch gerade rumgeschlagen.
    Also:
    Du kannst ssi einbinden, wenn über "print Newfile" eine tatsächlich vorhandene file generiert wird.
    Du kannst ssi nicht einfügen, wenn über "print" eine sozusagen virtuelle file erzeugt wird, da das script nur einmal geparst wird.
    Angeblich gibt es zwar möglichkeiten zu tricksen, aber die vorschläge klangen äußerst kühn und verwegen.
    gruß ralf

    1. Hm... Also, das Skript generiert eine virtuelle Seite via "Print" - wo ist der Unterschied zu "Print Newfile", wäre das eine Lösung?

      Gruß Stefan

      1. hi!

        Hm... Also, das Skript generiert eine virtuelle Seite via "Print" - wo ist der Unterschied zu "Print
        Newfile", wäre das eine Lösung?

        Ralf meint damit wahrscheinlich, du musst ein statisches .shtml-Dokument durch dein Perl-Skript erstellen
        lassen, das dann bei der Anzeige geparst wird. Das ist dann aber nicht mehr dynamisch, da ja alle
        möglichen dynamischen Seiten bereits vorliegen müssen, was den Sinn eines CGI-Skripts ad absurdum
        führt :)

        Warum sollte man auch SSI in CGI-Ausgaben zulassen. Eigentlich dürfte sicht alles, was mit SSI als
        Ausgabe in ein Dokument eingebunden werden kann, auch direkt in der für das CGI-Skript verwendeten
        Programmiersprache erledigt werden können.

        bye, Frank!

        1. Warum sollte man auch SSI in CGI-Ausgaben zulassen. Eigentlich dürfte sicht alles, was mit SSI als
          Ausgabe in ein Dokument eingebunden werden kann, auch direkt in der für das CGI-Skript verwendeten

          Ob man ssi angaben, wie z. B. eine Navigation durch cgi ersetzen kann, weiß ich nicht, aber mir wäre nicht ganz klar, wie das gehen sollte. Wenn man zum Beispiel dieses forum hier nähme und davon ausginge, daß die navigation via ssi in die seite eingefügt wurde, dann ist es doch so, daß bei einer änderung der include file auch alle abgelegten nachrichten ihre navigation ändern. Das geht aber doch nur, weil das cgi sript über print NEWFILE das ssi in die file eingebaut hat. Würde man dies ohne ssi erledigen, könte perl vielleicht die neuen dateien anpassen, wenn die navigation verändert wird, aber die alten nachrichten würden doch ihre alte navigation behalten. Oder?
          gruß ralf

          1. Ob man ssi angaben, wie z. B. eine Navigation durch cgi ersetzen kann, weiß ich nicht, aber mir wäre nicht ganz klar, wie das gehen sollte.

            Wenn Du per SSI eine Environment-Variable ansprechen oder eine Bedingung auswerten willst, dann geht das in einer Programmiersprache genauso.
            Willst Du mit SSI eine Datei includen, geht das mit open(), Einlesen, print() und close() mühelos.
            Willst Du mit SSI eine URL includen, dann nimmst Du LWP::Simple, saugst den Inhalt mit get() ab und gibst ihn mit print() aus.

            Wenn man zum Beispiel dieses forum hier nähme und davon ausginge, daß die navigation via ssi in die seite eingefügt wurde, dann ist es doch so, daß bei einer änderung der include file auch alle abgelegten nachrichten ihre navigation ändern.

            Niemand will die Include-Datei ändern - nur die Wirkung der SSI-Anweisung durch Programmcode dynamisch nachbilden.

            Das geht aber doch nur, weil das cgi sript über print NEWFILE das ssi in die file eingebaut hat.

            Nein, es reicht, den Inhalt in den erzeugten Ausgabestrom einzustreuen.

            Würde man dies ohne ssi erledigen, könte perl vielleicht die neuen dateien anpassen, wenn die navigation verändert wird, aber die alten nachrichten würden doch ihre alte navigation behalten. Oder?

            Das ist der falsche Weg. Die von mir beschriebene SSI-Emulation würde keine einzige Datei statisch ändern - sie würde bei jedem Aufruf den Inhalt des anzuzeigenden Dokuments dynamisch erzeugen (genau wie SSI auch).

      2. Hm... Also, das Skript generiert eine virtuelle Seite via "Print" - wo ist der Unterschied zu "Print Newfile", wäre das eine Lösung?

        hallo stefan,
        also ich bin ja nun auch wahrlich kein perl gott, sondern habe mich vor drei wochen mehr oder minder zwangsweise das erste mal mit perl beschäftigt und habe ein forum angelegt, daß auf der selben grundlage fußt, wie das selfhtml forum. Darum ist das auch ein schönes beispiel für den unterschied zwischen print und print newfile.
        Also:
        Wenn du ein forumsbeitrag in das formular schreibst und dann auf absenden klickst, dann erscheint doch eine weiße seite, auf der dein beitrag noch mal kurz wiederholt wird und steht, diese worte sind jetzt im forum zu lesen usw. Diese seite wird über den befehl print erzeugt und das bedeutet, wenn du dein formular verschickst, gibt das perl script diese seite als antwort an dich aus, aber der html code wird an deinen browser geschickt, ohne daß er in irgendeinem dokument auf der festplatte des html servers abgelegt ist. Wenn du die seite wegklickst, ist sie nicht mehr vorhanden und auch nicht mehr aufrufbar.

        Anders verhält es sich mit den forumsbeiträgen. Diese beiträge werden über print NEWFILE als html dokumente in irgendeinem ordner des selfhtml forums auf der festplatte des servers angelegt und sind damit auch wirklich physisch vorhanden. Du kannst sie jederzeit ansehen und darauf antworten. Das heißt der print newfile befehl erzeugt eine tatsächlich vorhandene file, die auch später noch in irgendeiner form abrufbar ist. Darum kannst du hier auch ssi z. B. für eine navigation einfügen.

        ich hoffe, ich konnte mich verständlich ausdrücken und habe keine sachlichen fehler in meine erklärung eingebaut.

        gruß ralf