Anker anspringen von perl aus

[BM]

Hallo,

Ich habe einen Script geschrieben der eine HTML-Seite aus verschieden Daten erzeugt die durch den Scriptaufruf spezifiziert werden(daher kann ich dort auch ein Sprungziel angeben) und sende diesen Script folgendermaßen an den Browser:

<Code>
 print "Content-type: text/html\n\n";
 print $seitendaten;
 print "\n\n";
</Code>

Nun möchte ich aber das der Browser gleich zu einem bestimmten Anker z.B. #Ziel springt.

Wie mache ich das?

BM

[Siechfred]

Hell-O!

Nun möchte ich aber das der Browser gleich zu einem bestimmten Anker z.B. #Ziel springt.
Wie mache ich das?

Mit Javascript, Perl ist dafür nicht geeignet.

Siechfred

[Christoph Schnauß]

hallo Siechfred,

Mit Javascript, Perl ist dafür nicht geeignet.

Ups? Warum sollst du dafür auch noch Javascript nehmen? Das ist aus meiner Sicht vollkommen überflüssig. Du kannst auch aus einem Perl-Script heraus eine Seite mit seitenname.htm#ankername aufrufen bzw. sie so zusammenbauen.

Grüße aus Berlin

Christoph S.

[BM]

Hallo Christoph S.

Ups? Warum sollst du dafür auch noch Javascript nehmen? Das ist aus meiner Sicht vollkommen überflüssig. Du kannst auch aus einem Perl-Script heraus eine Seite mit seitenname.htm#ankername aufrufen bzw. sie so zusammenbauen.

Leider bekommt der Browser aber den Scriptaufruf gesendet. z.b: /cgi-bin/progi.pl?parmeter1=maske&parameter2=daten

Wie soll dabei dann noch das #Ziel angebracht werden, denn das was ich sende ist doch das Ergebnis des Scriptaufrufs?

BM

[Struppi]

Leider bekommt der Browser aber den Scriptaufruf gesendet. z.b: /cgi-bin/progi.pl?parmeter1=maske&parameter2=daten

Wie soll dabei dann noch das #Ziel angebracht werden, denn das was ich sende ist doch das Ergebnis des Scriptaufrufs?

wie ruifst du das Skript auf?
Du solltest dann dort den Anker einbauen.

Struppi.

[BM]

Hi Strupi

wie ruifst du das Skript auf?
Du solltest dann dort den Anker einbauen.

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei">text</a>

Wenn ich nun #Ziel hinten ran hänge, dann wird doch parameter2 geändert und nicht ein Sprungziel definiert oder?

BM

[Christoph Schnauß]

hallo BM,

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei">text</a>
Wenn ich nun #Ziel hinten ran hänge, dann wird doch parameter2 geändert und nicht ein Sprungziel definiert oder?

Und warum baust du dir nicht gleich für parameter2 den Wert "daten.datei#ziel" zusammen?

Grüße aus Berlin

Christoph S.

[BerndM]

Hi, Christoph S.

BerndM == BM ok? hab mich registriert:-)

Und warum baust du dir nicht gleich für parameter2 den Wert "daten.datei#ziel" zusammen?

Weil ich ja keine redirektion mache a la location sondern nur einen HTML-Header sende Conten-type

Die Daten, die das Script ausgibt, existieren doch nicht als Datei auf dem Server, sondern werden nur für den Browser aus mehreren Dateien generiert.

Bis bald Bernd

[BerndM]

Hi,

Problem gelößt.

Denkfehler erkannt :-)

Ich rufe jetzt das Script wie folgt auf:
<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei&z=#Ziel">text</a>

Dadurch bekommt der Browser eine ordentliche Url und mein Parameter wird nicht versaut. Manchmal sieht man den Wald vor lauter Bäumen nicht. :-)

Gut das ich hier darüber schreiben kann. Danke für die Reflektionen.

Bis bald Bernd

[Struppi]

Ich rufe jetzt das Script wie folgt auf:
<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei&z=#Ziel">text</a>

Du hättest auch einfach:

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei#Ziel">text</a>

.. schreiben können, der Anker landet, zumindest wenn du sie mit dem CGI Modul auswertest, nicht in den Parametern.

Struppi.

[BerndM]

Hi, Struppi

Du hättest auch einfach:

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei#Ziel">text</a>

.. schreiben können, der Anker landet, zumindest wenn du sie mit dem CGI Modul auswertest, nicht in den Parametern.

Da ich aber ein eigenes CGI-Modul verwende, mußte ich das Problem selbst lösen :-)

Das mag ein Nachteil sein, aber so weiß ich wenigstens was passiert; und habe weniger overhead. Ich wollte nur bestimmte Fähigkeiten der CGI-Schnittstelle nutzen. Und vermeide so unkontrollierte Script-Teile. Außer lib.pm strict.pm CGI::Carp.pm Fcntl.pm und den Exporter mach ich bisher alles selbst. Natürlich ist CGI ein großes Vorbild.:-)

Bis bald Bernd

[Struppi]

Da ich aber ein eigenes CGI-Modul verwende, mußte ich das Problem selbst lösen :-)

Das mag ein Nachteil sein, aber so weiß ich wenigstens was passiert; und habe weniger overhead. Ich wollte nur bestimmte Fähigkeiten der CGI-Schnittstelle nutzen. Und vermeide so unkontrollierte Script-Teile. Außer lib.pm strict.pm CGI::Carp.pm Fcntl.pm und den Exporter mach ich bisher alles selbst. Natürlich ist CGI ein großes Vorbild.:-)

Naja, das Modul wird seit 1998 entwickelt, da hast du viel zu tun.

Ausserdem verwendet es einen Autload Mechanismus, d.h. es wird nur der Code übersetzt, der benötigt wird, also kaum overhead und "unkontrollierte" Skriptteile. Zumal es noch sehr, sehr viele Möglichkeiten beinhaltet, um HTML Code zu erzeugen.

"Selbst machen" ist am Anfang sicher nicht schlecht, aber man sollte die Module auf cpan im Auge behalten. Denn auch der Umgang mit Modulen will erlernt sein. Externe Module gehören in jeder Programmiersprache zum Alltag. Kaum einer käme auf die Idee das DBI oder Tk Modul selbst zu schreiben. Und gerade was plattformunabhängigkeit angeht sind die meisten Module weiter, als ein einzelner das alles rausfinden kann, was dort beachtet werden muss.

Struppi.

[BerndM]

Hi,

Naja, das Modul wird seit 1998 entwickelt, da hast du viel zu tun.

Eben nicht. Mein Modul steht seit 2000 und ich habe seither kaum Änderungen oder Erweiterungen benötigt. Es gibt zwei Versionen, das eine verarbeitet nur Parameter POST und GET und ein zweites auch uploads. Dadurch weiß ich definitiv, das bestimmte Scripte einfach keinen Upload zulassen, weil dort nur die erste Version verwendet wird.

"Selbst machen" ist am Anfang sicher nicht schlecht, aber man sollte die Module auf cpan im Auge behalten. Denn auch der Umgang mit Modulen will erlernt sein.

Ich gebe dir ja Recht, nur mein unbehagliches Gefühl, wenn ich einen Code nicht verstehe läßt sich nicht so einfach vertreiben.

»»Externe Module gehören in jeder Programmiersprache zum Alltag. Kaum einer käme auf die Idee das DBI oder Tk Modul selbst zu schreiben. Und gerade was plattformunabhängigkeit angeht sind die meisten Module weiter, als ein einzelner das alles rausfinden kann, was dort beachtet werden muss.

Dacore, doch bevor ich ein weiteres Modul einsetze, muß ich es wirklich kennen und möglichst wissen, wo es herkommt, wer es gemacht hat. Manchmal ist es auch besser zu überlegen, ob der Einsatz für das gegebene Problem überhaupt zu rechtfertigen ist oder eine einfachere Lösung möglich ist. Immerhin kostet es auch Zeit und Mühe den Umgang mit CPAN und dem jeweiligen Modul zu erlernen. Außerdem habe ich Angst irgendwann einmal an einer Lizenz bzw. Copyright-Hürde zu scheitern. Und dann der Aufwand ein bereits entwickeltes System umschreiben zu müssen. Es ist vielleicht übertrieben, aber wer weiß das schon. :-(

Bis bald Bernd

PS: Du hast trotzdem mein Handycap voll erkannt.

[Struppi]

Naja, das Modul wird seit 1998 entwickelt, da hast du viel zu tun.

Eben nicht. Mein Modul steht seit 2000 und ich habe seither kaum Änderungen oder Erweiterungen benötigt. Es gibt zwei Versionen, das eine verarbeitet nur Parameter POST und GET und ein zweites auch uploads. Dadurch weiß ich definitiv, das bestimmte Scripte einfach keinen Upload zulassen, weil dort nur die erste Version verwendet wird.

Dann benutzt du ein anderes CGI Mopdul, als das das üblicherweise bei Perl dabei ist. Ich benutze es seit ich Perl lerne also ca. 1998, damals war aber noch cgi-lib populär, aber das verwendet niemand.

Hier z.b. ist die Liste der Änderungen: http://search.cpan.org/src/LDS/CGI.pm-3.20/Changes
und da sind viele Anpassungen nach 2000 drin. Ich würde mal sagen, die meisten.

"Selbst machen" ist am Anfang sicher nicht schlecht, aber man sollte die Module auf cpan im Auge behalten. Denn auch der Umgang mit Modulen will erlernt sein.

Ich gebe dir ja Recht, nur mein unbehagliches Gefühl, wenn ich einen Code nicht verstehe läßt sich nicht so einfach vertreiben.

Wer schaut den den Code von Modulen an?
Du erwartest eine Dokumentierte Schnittstelle und getesteter Code, fertig!

Dacore, doch bevor ich ein weiteres Modul einsetze, muß ich es wirklich kennen und möglichst wissen, wo es herkommt, wer es gemacht hat. Manchmal ist es auch besser zu überlegen, ob der Einsatz für das gegebene Problem überhaupt zu rechtfertigen ist oder eine einfachere Lösung möglich ist. Immerhin kostet es auch Zeit und Mühe den Umgang mit CPAN und dem jeweiligen Modul zu erlernen.

Deshalb gibt es ja CPAN, die auch Regeln dafür aufstellen.

Außerdem habe ich Angst irgendwann einmal an einer Lizenz bzw. Copyright-Hürde zu scheitern.

Ich finde jetzt nicht die passende Seite, aber ich denke mal das die Module bei CPAN unter der gleichen Lizenz wie Perl veröffentlicht werden.

PS: Du hast trotzdem mein Handycap voll erkannt.

Ich kenne das.
am Anfang möchte man alles selber programmieren, aber du kannst dich nicht mit jeder Technik auseinandersetzen, bzw. verlierst du durch nebenschauplätze, dein Ziel aus den Augen.

Bevor ich das CGI Modul benutze habe, war ich monatelang damit beschäftigt,  ähnliche Funktionalität nachzuprogrammieren, bis ich bemerkte dass das Modul viel mehr und das was ich gemacht hatte auch viel besser konnte (ich habe z.b. erst Jahre später AUTOLOAD verstanden).

Struppi.

[BerndM]

Hi,

Dann benutzt du ein anderes CGI Mopdul, als das das üblicherweise bei Perl dabei ist.

Ja ich schrieb es 2000 selbst :-)

Hier z.b. ist die Liste der Änderungen: http://search.cpan.org/src/LDS/CGI.pm-3.20/Changes
und da sind viele Anpassungen nach 2000 drin. Ich würde mal sagen, die meisten.

Genau,als ich mir damals das CGI-Modul anschaute gab es noch kleine Probleme und die Dokus waren vorzugsweise in Englisch(eine weitere Schwäche von mir ist, das ich mir englisch-gelesenen Textinhalt einfach nicht merken kann).

Zum Verstehen der Moduleigenschften gehört bei mir dann immer auch die Suche nach deutschen Dokus. Alles Zeitaufwand. Betrachte ich die Zeit die ich brauchte um das für mich nötige zu programmieren war das erheblich weniger als die Suche nach diversen Dokus für diverse Module. Irgendwann dachte ich es ist genug mit suchen.

Wer schaut den den Code von Modulen an?

Ich :-)

Du erwartest eine Dokumentierte Schnittstelle und getesteter Code, fertig!

Deshalb gibt es ja CPAN, die auch Regeln dafür aufstellen.

Auch das ist wieder Zeitaufwand der dann allerdings für alle Regeln gelten sollte.

Ich finde jetzt nicht die passende Seite, aber ich denke mal das die Module bei CPAN unter der gleichen Lizenz wie Perl veröffentlicht werden.

Zugegeben bei Perl scheint mir die Gefahr verhältnismäßig gering, aber wenn selbst Linux ab und zu von großen Firmen angemacht wird... ...und die Sache mit den Software-Patenten ist auch noch lange nicht ausgestanden oder?

PS: Du hast trotzdem mein Handycap voll erkannt.
Ich kenne das.
am Anfang möchte man alles selber programmieren, aber du kannst dich nicht mit jeder Technik auseinandersetzen, bzw. verlierst du durch nebenschauplätze, dein Ziel aus den Augen.

Auch da sprichst du mir aus dem Herzen, für das was ich seit 1999 programmiere in Perl habe ich mir oft Mitarbeiter gewünscht und vor allem für viele Standards deutsche Dokumente. Jetzt war ich 1,75 Jahre aus Geldmangel offline und ich muß erstmal schauen was sich so alles getan hat. Isoliert zu sein und Teilnahme an der OpenSource-Gemeinde sind zwei paar Schuhe. Ich war also mehr auf mich selbst angewiesen.

Bevor ich das CGI Modul benutze habe, war ich monatelang damit beschäftigt,  ähnliche Funktionalität nachzuprogrammieren, bis ich bemerkte dass das Modul viel mehr und das was ich gemacht hatte auch viel besser konnte (ich habe z.b. erst Jahre später AUTOLOAD verstanden).

Als Autodidakt geht man oft seltsame Wege und kommt doch an manche Ziele, die von den regulär Lernenden nicht erkannt werden. Der regulär Lernende wundert sich aber andererseits darüber, warum beim Autodidakten an manchen Stellen seltsame Wissenslücken auftauchen. Beides hat Vor- und Nachteile.

Ich habe damals, 99, gerade das Computersystem gewechselt und die Programmiersprache. Viele Ideen vor dem Wechsel konnte ich mit Perl leichter realisieren. Und so unternahm ich den Versuch ein kleines objektorientiertes System zu entwickeln, das für das Internet geeignet war. Jeder Script-Aufruf generiert ein Objekt, dessen Methoden und Eigenschaften durch Parameter angesprochen werden, die in Unterobjekten stecken. So konnte ich die benötigten Funktionalitäten, die programmiert wurden, in den Objekten sammeln. Jeder Scriptaufruf hat demzufolge nicht nur Eingabeparameter, sondern auch immer eine entsprechende Ausgabe. Momentan gibt es login.pl, logout.pl, top.pl, frame.pl, und navi.pl die gut laufen. login und logout wird nur für PAsswortgeschützte Teile benötigt top enthält unter anderem auch die Möglichkeit Framesets auszugeben und frame gibt einfach in ein Frame also dem ganzen Fenster oder einem Teilfenster aus. Navi ist im Grunde wie Frame, doch wird ein Menü das ausklappbar ist in einem Frame ausgegeben. Ziel war eigentlich möglichst kleine Start-Scripte zu haben, die einerseits, das immer wiederkehrende identifizieren des Zustandes des Meta-Prozesses einer Web-Site ermöglichen und dabei andererseits auf einfache Art von außen steuerbar/konfigurierbar sind. Aber, obwohl die bisherige Funktionalität schon einiges hergibt, wäre es noch ein langer Weg allein daraus das zu machen, was dabei herauskommen könnte: Ein online-Content-Managment-System für XML, XSLT und HTML-Daten.

Bis bald Bernd

PS:Ist es überhaupt gewünscht, das wir diesen Faden hier weiter führen oder verstoßen wir gegen die Etikette?

[Struppi]

Dann benutzt du ein anderes CGI Mopdul, als das das üblicherweise bei Perl dabei ist.

Ja ich schrieb es 2000 selbst :-)

oops, ja, "mein" hatte ich überlesen.

Genau,als ich mir damals das CGI-Modul anschaute gab es noch kleine Probleme und die Dokus waren vorzugsweise in Englisch(eine weitere Schwäche von mir ist, das ich mir englisch-gelesenen Textinhalt einfach nicht merken kann).

Ich hab irgendwo auf meinem alten Rechner eine deutsche Doku aus der zeit.

Zum Verstehen der Moduleigenschften gehört bei mir dann immer auch die Suche nach deutschen Dokus. Alles Zeitaufwand. Betrachte ich die Zeit die ich brauchte um das für mich nötige zu programmieren war das erheblich weniger als die Suche nach diversen Dokus für diverse Module. Irgendwann dachte ich es ist genug mit suchen.

Bei mir dauert's meistens länger bis ich versteh, was ich überhaupt brauche. Ich merk das imer wieder beim stöbern im CPAN dass es da viele Module gibt, die mir das Leben vereinfachen könnten, aber dann hab ich die gleiche Problematik wie du, dass eben schon was eigenes steht.

Wer schaut den den Code von Modulen an?

Ich :-)

Ich schau da auch rein, aber es gibt ja nicht wenige Module, die kompiliert sind, also kein Quelltext.

Du erwartest eine Dokumentierte Schnittstelle und getesteter Code, fertig!

Deshalb gibt es ja CPAN, die auch Regeln dafür aufstellen.

Auch das ist wieder Zeitaufwand der dann allerdings für alle Regeln gelten sollte.

Jetzt drehst du dich aber im Kreis, wenn du in der Lage bist eine Funktionalität schneller und besser zu entwickeln, als andere mag der Zeitfaktor eine grosse Rolle spielen, aber ansonsten ist es durchaus sinnvoll auch mal nach Modulen Aussschau zu halten.

Als Autodidakt geht man oft seltsame Wege und kommt doch an manche Ziele, die von den regulär Lernenden nicht erkannt werden. Der regulär Lernende wundert sich aber andererseits darüber, warum beim Autodidakten an manchen Stellen seltsame Wissenslücken auftauchen. Beides hat Vor- und Nachteile.

Nur am Rande, ich kann auchn ur das was ich mir selbst beigebracht habe.

... Ziel war eigentlich möglichst kleine Start-Scripte zu haben, die einerseits, das immer wiederkehrende identifizieren des Zustandes des Meta-Prozesses einer Web-Site ermöglichen und dabei andererseits auf einfache Art von außen steuerbar/konfigurierbar sind.

Ich denke dass sind die Anforderungen die meistens an CGI Anwendungen gestellt werden. Da gibt es mittlerweile auch ein Modul das vielversprechend klingt http://search.cpan.org/~markstos/CGI-Application-3.21/
Ich aber bisher auch nur ein bisschen damit rumgespielt, da ein Umstieg eines bestehenden System immer heikel ist.

Aber, obwohl die bisherige Funktionalität schon einiges hergibt, wäre es noch ein langer Weg allein daraus das zu machen, was dabei herauskommen könnte: Ein online-Content-Managment-System für XML, XSLT und HTML-Daten.

und viele (meist englischsprachige) Dokumentationen.

PS:Ist es überhaupt gewünscht, das wir diesen Faden hier weiter führen oder verstoßen wir gegen die Etikette?

Nö.

Struppi.

[MudGuard]

Hi,

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei#Ziel">text</a>

.. schreiben können, der Anker landet, zumindest wenn du sie mit dem CGI Modul auswertest, nicht in den Parametern.

Der Fragment Identifier wird normalerweise gar nicht erst zum Server übertragen.

PS: wieviel Sedimentgestein (Löß) ist denn jetzt am Problem? Und wie kann man das wieder davon lösen?

cu,
Andreas

[Struppi]

<a href="/cgi-bin/progi.pl?parameter1=masken.datei&parameter2=daten.datei#Ziel">text</a>

.. schreiben können, der Anker landet, zumindest wenn du sie mit dem CGI Modul auswertest, nicht in den Parametern.

Der Fragment Identifier wird normalerweise gar nicht erst zum Server übertragen.

Es hat mich auch gewundert, aber ich hab's gar nicht probiert. D.h. es gibt gar kein Problem.

Struppi.

[Siechfred]

Hell-O!

Mit Javascript, Perl ist dafür nicht geeignet.
Ups? Warum sollst du dafür auch noch Javascript nehmen?

Ja, du hast Recht, mit HTML geht es natürlich auch.

Du kannst auch aus einem Perl-Script heraus eine Seite mit seitenname.htm#ankername aufrufen bzw. sie so zusammenbauen.

Das ist - glaube ich - nicht ganz das, was der OP wollte. Aber so funktioniert es: Wenn der Anker an der URL des Scripts dranhängt, versucht der Browser, in der Ergebnisseite zu diesem Anker zu springen. Mit Hilfe von Perl musst du nur noch dafür sorgen, dass es in der ausgelieferten Seite einen Anker mit dem gesuchten Namen gibt. Und einen Redirect wollte der OP ja nicht.

Siechfred

[BerndM]

Hi,Siechfred

Das ist - glaube ich - nicht ganz das, was der OP wollte. Aber so funktioniert es: Wenn der Anker an der URL des Scripts dranhängt, versucht der Browser, in der Ergebnisseite zu diesem Anker zu springen. Mit Hilfe von Perl musst du nur noch dafür sorgen, dass es in der ausgelieferten Seite einen Anker mit dem gesuchten Namen gibt. Und einen Redirect wollte der OP ja nicht.

Ich muß inzwischen zu meiner Schande gestehen, das ein anderes Problem mir die unerklärliche Fehler-Seite verschaffte. Durch meine Aktion mit zusätzlichem Parameter hatte ich allerdings dieses Problem umgangen. Jetzt funktionierts auch ohne zusätzlichem Parameter. :-)

Frag ich dennoch nochma janz dumm:
Heißt das dann nicht auch, das ein # immer maskiert werden muß, wenn es in einem Parameter übergeben werden soll? oder wird nur das letzte # nicht zum Server geschickt?

Bis bald Bernd

[Siechfred]

Hell-O!

Heißt das dann nicht auch, das ein # immer maskiert werden muß, wenn es in einem Parameter übergeben werden soll? oder wird nur das letzte # nicht zum Server geschickt?

Laut RFC 3986 (Abschnitt 3) besteht eine URL aus folgenden Bausteinen (mal ins Vulgärdeutsche übertragen):

Protokoll ":" Domain/Pfad "?" Querystring "#" Anker

Querystring darf alles außer den reservierten Zeichen enthalten, zu denen laut Abschnitt 2.2 auch die Raute "#" gehört. Ergo musst du eine Raute, die Bestandteil des Querystrings ist, kodieren, lediglich die Raute, die den Anker vom Querystring trennt, bleibt unkodiert. So würde aus der Raute im Querystring ein "%23" werden müssen.

Siechfred

[BerndM]

Hi, Siechfred

Protokoll ":" Domain/Pfad "?" Querystring "#" Anker

Danke, nach 1,75 Jahren Internet-Abstinenz diese Hilfe von euch, das tut gut.

Bis bald Bernd

[BM]

Mit Javascript, Perl ist dafür nicht geeignet.

An anderer Stelle dieses Forums wird gesagt, Javascript hat mit Ankern nichts zutun.

Das verwirrt mich jetzt.

Ich hatte auch vermutet, aber zu wenig Ahnung von Javascript, das ich irgendwie per body + eventhandler (oderso?) die Sache realisieren kann. einen entsprechenden Scriptteil könnte ich ja durch das Perl-Script einbauenlassen.

BM

[Christoph Schnauß]

hallo,

Ich habe einen Script geschrieben

Nein, das hast du nicht. Scripts sind bedauerlicherweise nicht männlich.

Nun möchte ich aber das der Browser gleich zu einem bestimmten Anker z.B. #Ziel springt.

Was hindert dich daran, das so anzugeben?

Grüße aus Berlin

Christoph S.