nicht angemeldet
Weiterleitung als Return
Hallo!
Ich habe eine PHP-Seite (update.php), die eine Datenbank aktualisiert und eine andere Seite, welche die Daten darstellt (ausgabe.php). Die Ausgabe sieht in etwa so aus:
| Nr. | Bezeichnung | Wert | Stand |
|--------------------------|----------|
| 01 | Beispiel | 100 | 07.01.15 |
| 02 | Muster | 50 | 06.01.15 |
| ... | ... | ... | 07.01.15 |
update.php aktualisiert den Datensatz mit den jeweils ältesten Stand oder den per Get übergebenen.
Nun würde ich gerne in ausgabe.php in der jeweiligen Zeile einen Link einfügen, der update.php mit den jeweiligen Get-Parameter aufruft. Also in etwa so:
<table>
<tr>
<th>Nr.</th>
<th>Bezeichnung</th>
<th>Wert</th>
<th>Stand</th>
</tr>
<tr>
<td>01</td>
<td>Beispiel</td>
<td>100</td>
<td><a href="../update.php?id=123" title="Datensatz aktualisieren">07.01.05</a></td>
</tr>
...
</table>
Das ist wohl ein typischer Anwendungsfall für AJAX, aber ich suche nach einer Lösung ohne JS.
Deshalb habe ich mir gedacht, dass es vlt. auch ohne geht, indem ich von update.php entweder eine zeitverzögerte Weiterleitung zurück nach ausgabe.php einrichte oder (besser) eine Weiter-/Rückleitung als Return einrichte. Dies sind aber bisher rein theoretische Ansätze.
Ist dies wie gedacht möglich? Gibt es andere Möglichkeiten (ohne JS) oder komme ich um AJAX nicht herum?
FG
Alex
-
Hi,
Deshalb habe ich mir gedacht, dass es vlt. auch ohne geht, indem ich von update.php entweder eine zeitverzögerte Weiterleitung zurück nach ausgabe.php einrichte oder (besser) eine Weiter-/Rückleitung als Return einrichte.
„Als Return“ ergibt wenig Sinn.
Du rufst dein Script update.php auf, das verrichtet seine Arbeit – und leitest dann mittels header() wieder auf das Anzeigescript zurück. Das war’s.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/-
Hallo ChrisB,
vielen Dank für deine Antwort.
„Als Return“ ergibt wenig Sinn.
Ok. Der Gedanke an Return war nur, dass ich ausgabe.php ja eigentlich erst aufrufen will, wenn das Update gelaufen ist und ich nicht weiß, wann dies erledigt ist.
1. Holen der externen Werte
2. Aktualisieren der internen DB
3. Rückleitung an ausgabe.phpDu rufst dein Script update.php auf, das verrichtet seine Arbeit – und leitest dann mittels header() wieder auf das Anzeigescript zurück. Das war’s.
Das werde ich mal ausprobieren. Vielen Dank.
-
Hallo nochmal!
Du rufst dein Script update.php auf, das verrichtet seine Arbeit – und leitest dann mittels header() wieder auf das Anzeigescript zurück. Das war’s.
Das scheint so nicht zu funktionieren.
Das Updatescript läuft ohne Weiterleitung.
Füge ich nach dem Updatescript nun jedoch folgende Zeile ein:
// Weiterleitung, wenn dies per Get übergeben wurde $weiterleitung_aktiv = $_GET['wltg']; if($weiterleitung_aktiv == 1) { header("Location: http://www.example.org"); exit; }läuft das Update nicht. Es wird weitergeleitet, jedoch sind die Werte nicht die aktualisierten.
-
Habe gerade noch einen Fehler entdeckt (hab scheinbar die Weiterleitung zu früh eingefügt). Ich prüfe das!
-
Tach!
[code lang=php]// Weiterleitung, wenn dies per Get übergeben wurde
$weiterleitung_aktiv = $_GET['wltg'];
if($weiterleitung_aktiv == 1) {Warum machst du dir so viel Arbeit?
if (!empty($_GET['wltg']))
ist deutlich kürzer, weil es direkt auf den anzufragenden Wert zugrift. Außerdem erzeugt empty() keine Notice-Meldung, wenn wltg nicht in der URL existiert.
dedlfix.
-
Vielen Dank, dass du - trotz meiner spärlichen Code-Preisgebung - auch Anregung losgelöst von der Fragestellung gibst :-)
if (!empty($_GET['wltg']))
ist deutlich kürzer, weil es direkt auf den anzufragenden Wert zugrift. Außerdem erzeugt empty() keine Notice-Meldung, wenn wltg nicht in der URL existiert.
Gedanke bei der Zwischenspeicherung in der Variablen war, dass ich auch an anderer Stelle (die ich euch vorbehalten habe, auch nochmal darauf zugreife.
Ich habe auch bei meinem Update unterschiedliche Abzweigungen.
Sinngemäß:
if($wert > 0) { /*1. DB-Update inkl. Wertaktualisierung */ /*2. Weiterleitung + exit (wenn $weiterleitung_aktiv) */ /*3. Ausgabe "Update erfolgt"*/ } else { /*1. DB-Update (nur Stand) */ /*2. Weiterleitung + exit (wenn $weiterleitung_aktiv) */ /*3. Ausgabe "kein Update"Ich werde das aber anpassen; insbesondere wegen der Notice-Meldung.
-
Tach!
Gedanke bei der Zwischenspeicherung in der Variablen war, dass ich auch an anderer Stelle (die ich euch vorbehalten habe, auch nochmal darauf zugreife.
Auch dann wird der Wert in $_GET unverändert zur Verfügung stehen. Du wirst ihn doch dort nicht absichtlich überschreiben?
Eine Speicherung des (unveränderten) Wertes in einer anderen Variable kann ich mir nur dann als Szenario vorstellen, wenn man diesen Wert einer Funktion übergibt, die was generelles tut und von GET etc. keine Ahnung hat (/haben muss). Dann übergibt man das $_GET... als Parameter und nimmt es in der Funktion in einer Parameter-Variable entgegen.
dedlfix.
-
Auch dann wird der Wert in $_GET unverändert zur Verfügung stehen. Du wirst ihn doch dort nicht absichtlich überschreiben?
Überschrieben hab ich ihn nicht, aber ich tat es ...
... vielleicht aus Gewohnheit?
Meist weise ich - gerade bei umfangreicheren Scripts - im Kopf die Get-Parameter erstmal "normalen" Variablen zu und arbeite dann im weiteren Verlauf damit. Dann sehe ich auf einem Blick, welche Get-Parameter möglich sind und kann ggf. auch direkt Defaultwerte zuweisen, wenn nichts übergeben wird.. Hat natürlich den Nachteil, dass man ggf. im weiteren Script nicht auf Anhieb weiß, woher die Daten in der Variablen kommen. Einen Tod muss man wohl sterben. Aber das hat mich hier wohl nicht dazu veranlasst; gerade weil die Variablenzuweisung nicht im Kopf (= im Scriptkopf) stattgefunden hat.... vielleicht der Einfachheit zu Liebe?
In der weiteren Verarbeitung finde ich es dann auch einfacher mit einem einfachen Variablennamen zu arbeiten ($beispiel) als mit $_GET['beispiel']; gerade wenn die Variable mehrmals verwendet wird. Möglich, dass mich dies dazu bewogen hat.... vielleicht für einen sauberen Programmierstil?
Letztlich habe ich auch noch vermutet, dass der Zugriff auf $beispiel minimal schneller ist, als auf $_GET['beispiel']. Also weniger schneller, im Sinne von merkbar schneller, sondern mehr im Sinne von sauberer programmiert.... eher einfach so, weil ich es nicht besser wusste?
Es war wohl eher sowas wie: Ich versuche es mal so, es funktioniert, so lass ich es ... bis mich jemand eines besseren belehrt :)-
Tach!
Meist weise ich - gerade bei umfangreicheren Scripts - im Kopf die Get-Parameter erstmal "normalen" Variablen zu und arbeite dann im weiteren Verlauf damit. Dann sehe ich auf einem Blick, welche Get-Parameter möglich sind ...
Programmdokumentation kann man auch in Kommentare schreiben.
... und kann ggf. auch direkt Defaultwerte zuweisen, wenn nichts übergeben wird..
Das ist eine "legitime" Anwendung. Damit fängst du ja schon an, mit den Daten sinnvoll zu arbeiten. Dazu gehört auch ein eventuell notwendiges Dekodieren.
Hat natürlich den Nachteil, dass man ggf. im weiteren Script nicht auf Anhieb weiß, woher die Daten in der Variablen kommen.
Wenn ein Projekt zu groß wird, so dass man die Übersicht zu verlieren droht, hilft vermutlich auch das Belassen in $_GET/$_POST nicht mehr viel. Dann sollte man sich vielleicht doch mal anschauen, wie ein modernes Framework funktioniert und wie es dabei helfen kann, die Übersicht wiederzuerlangen.
... vielleicht der Einfachheit zu Liebe?
In der weiteren Verarbeitung finde ich es dann auch einfacher mit einem einfachen Variablennamen zu arbeiten ($beispiel) als mit $_GET['beispiel']; gerade wenn die Variable mehrmals verwendet wird. Möglich, dass mich dies dazu bewogen hat.Das Argument kenne ich. Es wird auch gern ohne nachzudenken selbst bei einmaliger Anwendung umkopiert, wodurch das Script sogar noch etwas länger wird.
... vielleicht für einen sauberen Programmierstil?
Letztlich habe ich auch noch vermutet, dass der Zugriff auf $beispiel minimal schneller ist, als auf $_GET['beispiel']. Also weniger schneller, im Sinne von merkbar schneller, sondern mehr im Sinne von sauberer programmiert.Auf die Geschwindigkeit, die sich damit rauskitzeln lässt, kommt es in der Regel nicht an. Mikrooptimierung hinterlässt auf einem Server meist keine praktisch relevante Verbesserung. Es ist wichtiger, dass die Entwicklungs- und Wartungszeiten minimiert werden, als einmalig drei Euro fuffzich mehr für einen besseren Server zu bezahlen.
Es ist nicht generell schlecht, die Herkunft von Werte wegzuabstrahieren, aber es sollte wie bei jeder Tätigkeit am besten eine nachvollziehbare Begründung gegeben werden können und ein Nutzen sichtbar sein.
dedlfix.
-
-
-
-
-
-
Vielen Dank. Es funktioniert, wie von dir beschrieben.
-
-
Tach!
update.php aktualisiert den Datensatz mit den jeweils ältesten Stand oder den per Get übergebenen.
Auch das scheint mir ein Fehler zu sein. Wenn da mal einen Linkchecker der eine Suchmaschine drüberläuft, dann sind da jede Menge Daten geändert? Daten ändernde Requests sollten immer nur mit POST aufgerufen werden können.
dedlfix.
-
Tach dedlfix.
update.php aktualisiert den Datensatz mit den jeweils ältesten Stand oder den per Get übergebenen.
Auch das scheint mir ein Fehler zu sein. Wenn da mal einen Linkchecker der eine Suchmaschine drüberläuft, dann sind da jede Menge Daten geändert? Daten ändernde Requests sollten immer nur mit POST aufgerufen werden können.
Danke für den Hinweis. Dies ist in diesem speziellen Fall nicht weiter schlimm. Vom Prinzip ist es gewünscht, dass die Daten immer möglichst aktuell sind. Es wird sowieso per Cronjob im 5 Minutentakt, der jeweils älteste Datensatz aktualisiert. Leider kann ich von der Quelle nur einzelne Datensätze beziehen. Da es bei knapp 50 Datensätzen dennoch zu bis zu 250 Minuten "überholten" Datensätzen kommen kann, wollte ich auch ein "manuelles"/"bedarfsweises" Update ermöglichen.
-