js in cgi einbinden
xpfreund
- perl
Hallo,
also in meinem cgi-Skript soll eine js-Datei integriert werden.
Das mache ich so:
print "<script src=\"test.js\" type=\"text/javascript\"></script>";
Mein Problem ist, dass im Webdeveloper die test.js nen Serverfehler zurückgibt und entsprechende Funktionsaufrufe in der Datei schief gehen.
Muss ich jetzt etwa in jede Zeile der js-Datei nen print schreiben?
Oder gibts irgendeine Anweisung, die ich beim Einbinden oder in der js-Datei angeben kann, damit die korrekt geparst wird?
gruß aus Senftenberg am See
Hi,
also in meinem cgi-Skript soll eine js-Datei integriert werden.
Das mache ich so:
print "<script src=\"test.js\" type=\"text/javascript\"></script>";
Und das Ergebnis ist?
(Zwar vorhersehbar, aber du solltest trotzdem bei clientseitigen Problem in den Quelltext schauen - *immer*.)
Mein Problem ist, dass im Webdeveloper die test.js nen Serverfehler zurückgibt und entsprechende Funktionsaufrufe in der Datei schief gehen.
Drücke dich bitte präzise aus - „ein Serverfehler“ ist wischi-waschi.
Muss ich jetzt etwa in jede Zeile der js-Datei nen print schreiben?
Natürlich nicht. Du musst es nur richtig machen.
Um zu beurteilen, was du falsch gemacht hast, hast du uns bisher viel zu wenig relevante Informationen geliefert.
Oder gibts irgendeine Anweisung, die ich beim Einbinden oder in der js-Datei angeben kann, damit die korrekt geparst wird?
Wie immer gilt auch hier: Wenn du ein Problem hast, an dem zwei Techniken gleichzeitig beteiligt sind - dann eliminiere zunächst eine davon.
Bastle dir eine statische Version des Dokuments, an dem Perl mit Nullkommanull Prozent beteiligt ist - und sorge dafür, dass in dieser das JavaScript korrekt eingebunden ist, und wie gewünscht und ohne Fehler arbeitet.
Anschliessend kannst du dein Dokument mit Perl dynamisch erzeugen. Wenn du dabei auf Probleme stößt - dann vergleiche jeweils, welche Unterschiede zur statischen Version bestehen.
Warum man dieses Vorgehen hier immer wieder *erklären* muss, ist mir übrigens schleierhaft - m.E. fällt es unter gesunden Menschenverstand, in solchen Fällen so und nicht anders vorzugehen.
MfG ChrisB
moin,
Oder gibts irgendeine Anweisung, die ich beim Einbinden oder in der js-Datei angeben kann, damit die korrekt geparst wird?
Es gibt auf jeden Fall einen schöneren Schreibstil für die print-Anweisung, womit das Maskieren der Spezialzeichen entfallen kann:
print qq(
<script type="text/javascript" src="/mylib.js">
</script>
);
print qq(
<script type="text/javascript">
var x = {};
alert("$perlvariable");
</script>
);
Du siehst im 2. Beispiel, wie einfach es ist, da eine $perlvariable mitzugeben. Wenn alles linksbündig steht, geht aus das HERE-Konstrukt:
print <<"TOKEN";
// JavaScript
TOKEN
Und schaffe klare Verhältnisse, was Pfadangaben betrifft. Eine Angabe wie
src="x.js"
solltest Du Dir abgewöhnen, selbst dann, wenn x.js im gleichen Verzeichnis ist, wie das Perl(CGI)script. Es gibt für Scripts in /cgi-bin/ kein "Arbeitsverzeichnis" was ebenso /cgi-bin/ heißt, es gibt eine Umgebung %ENV und wenn Du da reinschaust, wirst Du sehen, dass alle Pfadangaben mit einem "/" beginnen. Mach es genauso, der "/" bezieht sich immer auf DOCUMENT_ROOT, sofern es sich nicht um eine virtuelle Pfadangabe handelt wie ScriptAlias /cgi-bin/ sondern um physikalisch vorhandene Ressourcen wie JS oder HTML-Dateien.
Hottü
Hallo,
Es gibt auf jeden Fall einen schöneren Schreibstil für die print-Anweisung, womit das Maskieren der Spezialzeichen entfallen kann:
Und schaffe klare Verhältnisse, was Pfadangaben betrifft. Eine Angabe wiesrc="x.js"
Dann so:
print qq(
<script src="/cgi-bin/ar.js" type="text/javascript">
</script>
);
Du siehst im 2. Beispiel, wie einfach es ist, da eine $perlvariable mitzugeben. Wenn alles linksbündig steht, geht aus das HERE-Konstrukt:
print <<"TOKEN";
// JavaScript
TOKEN
Also wenn ich das Konstrukt nehme, kommt die gleiche Meldung für das gesamte Skript, wie bei Webdeveloper oder der Quelltextanzeige für die js-Datei kommt:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
webmaster@mehr-klicks-auf-youtube-videos.de and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>
Dann werd ich jetzt mal testen, obs ohne Perl gehen würde.
gruß aus [Senftenberg](http://www.senftenberg.de/) am [See](http://www.senftenberger-see.de/)
Hallo,
das wundert mich jetzt.
Habe die js in ein anderes Verzeichnis, was die Berechtigungen auch auf 755 stehen hat, aus cgi-bin verschoben und da wird sie anstandslos ordentlich eingebunden. Scheint wohl ne Einstellung aufm Webserver zu sein, die in dem Verzeichnis keine JS.Dateien haben will.
Warum aber das mit dem Konstrukt bei gleicher Anwendung wie in der Originalfunktion nicht funktioniert, ist mir schleierhaft.
gruß aus Senftenberg am See
hi,
Habe die js in ein anderes Verzeichnis, was die Berechtigungen auch auf 755 stehen hat, aus cgi-bin verschoben und da wird sie anstandslos ordentlich eingebunden. Scheint wohl ne Einstellung aufm Webserver zu sein, die in dem Verzeichnis keine JS.Dateien haben will.
Nochma zum Verständnis, ich hatte das heute morgen schon geschrieben: /cgi-bin/ ist ein virtuelles Verzeichnis (ScriptAlias), es ist im Webserver so konfiguriert, dass eine Anforderung, ein HTTP-Request an /cgi-bin/datei vom Webserver ausgeführt werden will. Genau diesen Sachverhalt findest Du im Error-Log (danke Cheatah) weil ein .js auch mit chmod 755 eben nicht ausführbar ist (shebang fehlt).
Hottüüüü
Hi,
<title>500 Internal Server Error</title>
[...]
<p>More information about this error may be available
in the server error log.</p>
mir ist nicht klar, warum Du bei einem Internal Server Error etwas anderes machst als das, was in eben dieser Meldung geraten wird.
Cheatah
Hallo,
Hi,
<title>500 Internal Server Error</title>
[...]
<p>More information about this error may be available
in the server error log.</p>mir ist nicht klar, warum Du bei einem Internal Server Error etwas anderes machst als das, was in eben dieser Meldung geraten wird.
Cheatah
Liegt daran, dass ich um die Serverlog einzusehen erstma den Support anmailen muss.
gruß aus Senftenberg am See
mir ist nicht klar, warum Du bei einem Internal Server Error etwas anderes machst als das, was in eben dieser Meldung geraten wird.
CheatahLiegt daran, dass ich um die Serverlog einzusehen erstma den Support anmailen muss.
schreibe in alle deine Perl-Scripte
BEGIN {
use CGI::Carp qw(carpout);
open(LOG, ">>error.txt") or die "Unable to append to error.txt: $!\n";
carpout(*LOG);
}
Lege eine Datei error.txt in das Verzeichnis (-rw), in welchem auch das Script liegt.
Alle Warnungen werden dann in diese Datei umgeleitet.
Und nochmals: Du solltest deine Scripte local entwickeln und testen.
Installier dir Perl (zB ActiveState für windows )
und hol dir einen Apachen.
mfg Beat
Hi,
Liegt daran, dass ich um die Serverlog einzusehen erstma den Support anmailen muss.
dann hast Du einen Vertrag geschlossen, der nicht mit serverseitiger Entwicklung kompatibel ist. Das Error-Log ist *Pflichtbestandteil*, wenn Du *irgendwas* auf Serverseite machst. Du kaufst doch auch kein Auto, dessen Tankdeckel nur von einer Vertragswerkstatt geöffnet werden kann, oder?
Cheatah