PERL mit Zugriff auf Quelltext
WileECoyote
- perl
0 Cheatah0 WileECoyote0 Rolf0 Cheatah
0 Michael Schröpl
Hab ein delikates Problem... vielleicht kann mir jemand von euch helfen....
Folgendes: ich habe eine Seite gebaut die über einen Frame realisiert wird. Die Navigation im Topframe und der Inhalt im zweiten Teil. Der Topframe enthält ein Formular das gewisse Auswahlmöglichkeiten bietet die eben dann zur Bildung der Seite im zweiteren Frame führt. Mein Problem dazu ist nun konkret das diese Art Navigation die ich geschaffen habe eine Art Linie bilden soll. Ich will also bevor das Perlscript wieder eine neue Seite aufbaut es die alte Seite nochmals nach bereits vorhandenen Daten ausliest. Wie kann ich nun das realisieren auf eine Seite zuzugreifen die ja eigentlich nur eine kurzzeitige Lebensdauer hat und nicht gespeichert ist... oder vielleicht kann man ja den Quelltext irgendwie auslesen... wer kann mir helfen?
lg Wile
Hi,
Ich will also bevor das Perlscript wieder eine neue Seite aufbaut es die alte Seite nochmals nach bereits vorhandenen Daten ausliest.
also, ich habe zwar nicht wirklich verstanden was Du willst, kann Dir aber drei Dinge nennen, die Du offenbar noch nicht weißt:
1.) HTTP weiß nichts über Fenster und Frames. Es existiert kein Weg, über HTTP (sprich: über etwas Serverseitiges) irgendein Fenster in welcher Weise auch immer anzusprechen.
2.) HTTP ist zustandslos. Es existiert kein "bereits vorhandene Daten", es gibt kein "vorher". Der Client schickt einen Request an den Server, der Server schickt eine Antwort - das ist alles, was passiert, mehr gibt es nicht.
3.) Client und Server sind zwei vollkommen unterschiedliche Universen. Sie haben absolut nichts miteinander zu tun. Bei der Kommunikation, z.B. HTTP, wird kurzzeitig ein Wurmloch zwischen beiden geöffnet, welches (je nach Protokoll) direkt nach der Benutzung wieder kollabiert. Anschließend gibt es nicht einmal mehr einen Hinweis darauf, dass der jeweils andere überhaupt existiert. Dementsprechend ist es völlig unmöglich, auf Serverseite irgendetwas zu ermitteln, was auf Clientseite vorherrscht; es sei denn, bei der "Reise" werden die Informationen mit übermittelt - was aber in aller Regel nicht passiert.
Wie gesagt, ich habe Dich nicht vollständig verstanden. Allerdings denke ich, dass Du ob dieser Informationen Dein Vorhaben durch ein neues Konzept ersetzen werden musst.
Cheatah
OK *g* dann anders *G*
mein Problem liegt konkret dass ich die Steuerung in einen eigenen Frame werfen muss... diese Steuerung regelt den Zugriff auf eine Datenbank und lässt dem User die Möglichkeit zu bestimmen wieviele Datensätze er am Bildschirm aufgebaut haben möchte... oder das Sortierverfahren...
konkret liegt nun das Problem in eben diesen persönlichen Daten... wenn derjenige sich aussucht eben 20 Zeilen pro Klick dargestellt zu haben... so muss ich in der Datenbank auch diese 20 Datensätze immer weitergehen. Mir fehlt (momentan bereite ich eh was neues vor also könnte es nimmer so notwendig sein) also die direkte Connection wieviele Datensätze sich der Typ bereits angesehen hat.
Und auch wenns nur Clientseitig ist *g* der Client stellt noch immer die Anfrage an den Server und diesen Client wirds anzipfen wenn er immer die gleichen Datensätze bekommt *g*
lg Wile
hi,
also ich hab das immer so gemacht, dass ich die Daten des Benutzers im Browser selbst gespeichert habe - in hidden Feldern und diese dann im weiteren Verlauf eines CGIs auslese.
Beispiel eines MINI Warenkorbs:
http://www.i-netlab.de/cgi-bin/tbest.cgi
Schau's Dir mal an ;-)
Rolf
Hi,
also ich hab das immer so gemacht, dass ich die Daten des Benutzers im Browser selbst gespeichert habe - in hidden Feldern und diese dann im weiteren Verlauf eines CGIs auslese.
genau das, oder in URL-Parametern von Links beispielsweise. Generiere die Seite grundsätzlich immer so, dass sie völlig alleine stehen kann - in einem frisch installierten Browser als voreingestellte Startseite - und trotzdem funktioniert. Es gibt für diese Seite keine anderen Frames.
Cheatah
Hi Wile,
Mir fehlt (momentan bereite ich eh was neues vor also könnte es nimmer
so notwendig sein) also die direkte Connection wieviele Datensätze
sich der Typ bereits angesehen hat.
also mußt Du diese Information in den entsprechenden Frame transportieren.
Dafür gibt es m. E. zwei Möglichkeiten:
1. Du berechnest sie bereits in diesem Frame - d. h. Du startest die
Anzeige immer mit CGI-Parametern, welche den Offset für die Anzeige
vollständig beschreiben. Der Steuer-Frame ist also der "Master", der
Anzeige-Frame der "Slave". Dazu müßtest Du innerhalb des Masters
ein Gedächtnis führen (was nach JavaScript riecht).
2. Du berechnest sie im "Slave" und transportierst das Wissen zurück in
den Master - auch das würde JavaScript erfordern. Dabei ist es Deine
Entscheidung, ob Du
a) im Slave JavaScript-Code ausgibst (z. B. eine Funktion), der Daten
in den Master schreibt, oder
b) im Slave JavaScript-Code ausgibst (z. B. eine Variable), der vom
Master aus gelesen werden kann.
Beides ist natürlich komplexer, als wenn Du ausschließlich im Slave
alles Wissen über die Navigation ansiedeln würdest - d. h. wenn Du etwa
das neue Suchformular serverseitig generieren und dort ausgeben würdest.
Frames sind an dieser Stelle wirklich ein Hindernis, welches mit ent-
sprechender client-seitiger Programmierung behandelt werden muß.
Viele Grüße
Michael
(der eine Suchmaschine betreibt, deren Eingabeformular (!) über mehrere
Frames verteilt ist und erst beim Submit dynamisch alle Werte einsammelt)