Verschiedene Ajax Requests, nur eine PHP ?
0 0 Danke
0 0 0 0 
molily
Verschiedene Ajax Requests, nur eine PHP ?
Hallo zusammen,
in einer Webanwendung gibt es mehrere Ajax Requests für unterschiedliche Aufgaben:
Im Beispiel unten wird ja die Datei "getdays.php" aufgerufen. Diese wiederum liefert eine Anzahl Stunden aus einer DB.
$sqldata = get_sumhours($number);
$sqldatajson = json_encode($sqldata);
echo $sqldatajson;
Durch die vielen unterschiedlichen Requests gibt es nun schon ca. 6 PHP Dateien, für verschiedene DB Abfragen.
Würde es eine Möglichkeit geben, nur eine PHP Datei wie "ajax.php" zu nehmen, in der aber unterschiedliche DB Abfragen drin sind?
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?
$.ajax({
type: "GET",
url: "getdays.php",
data: {
ynumber: pnr
},
dataType : "json",
success: function(data) {
var gesamthours = data['phours'];
$("#txt_manhours").val(gesamthours);
}
});
vielen Dank und viele Grüße
hawk
-
Hi,
Würde es eine Möglichkeit geben, nur eine PHP Datei wie "ajax.php" zu nehmen, in der aber unterschiedliche DB Abfragen drin sind?
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?So z.B.:
$.ajax({
type: "POST",
url: "ajax.php",
data: {
ynumber: pnr,action: 'getDays'
}, dataType : "json", success: function(data) { var gesamthours = data['phours']; $("#txt_manhours").val(gesamthours); }});
Und in deinem ajax.php könnte es dann so ausschauen: ~~~php switcht($_POST['action']) { case 'getDays': /// mach was break; case 'etwasAnderes': /// mach was break; default: //error }MfG Naps
-
Hallo zusammen,
vielen Dank an alle für die Ideen und Hilfsansätze.
Gruss
Hawk
-
-
Moin,
Würde es eine Möglichkeit geben, nur eine PHP Datei wie "ajax.php" zu nehmen, in der aber unterschiedliche DB Abfragen drin sind?
Natürlich.
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?
Mit weiteren Parametern, die übergeben werden.
$.ajax({
type: "GET",
url: "ajax.php",// <------------------------------ einfach ändern
data: {
ynumber: pnr,
action: "getdays" <----------------------- einfach weiteren Parameter hinzufügen
},
dataType : "json",
success: function(data) {
var gesamthours = data['phours'];
$("#txt_manhours").val(gesamthours);
}
});In PHP kannst du dann das $\_POST-Array auswerten, speziell natürlich $\_POST['action']. Wahlweise könntest du auch $\_GET-Parameter nehmen, beispielsweise indem du bei url sowas wie "ajax.php?action=getdays" eingibst. Ich persönlich gebe auch immer noch einen Status mit zurück, wenn ich sowas baue. Die Struktur der Rückgabedaten ist dann: ~~~javascript { "status": "OK", // Wahlweise "ERROR", damit weiß man dann ob alles korrekt gelaufen ist. { "data1": "wert", "data2": ... ... } // Rückgabeobjekt }Grüße Marco
--
Ich spreche Spaghetticode - fließend. -
Moin
zu den schon genannten Lösungen vielleicht noch ein alternativer Lösungsansatz. Du kannst dir auch alle DAten in einer PHP zusammmensammeln und zum Beispiel nur 1 Mal per JSON übergeben. Damit minimierst du den Traffic und ich denke so viele Daten werden es nicht sein die du benötigst.
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
### Henry L. Mencken ###
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
### Viktor Frankl ###
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:) -
hi,
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?
entweder mit Parametern im Request oder mit einer zweckmäßigen Datenstruktur die bei jedem Request gesendet wird und die für das, was serverseitig zu tun ist, die entsprechenden Schlüssel enthält. Oder beides kombiniert.
MfG
-
Hi,
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?
entweder mit Parametern im Request oder mit einer zweckmäßigen Datenstruktur die bei jedem Request gesendet wird und die für das, was serverseitig zu tun ist, die entsprechenden Schlüssel enthält. Oder beides kombiniert.
Wenn man diesen Weg geht, dann aber bitte nichts neues erfinden. Wie wäre es dann mit etwas wie JSON-RPC?
Abgesehen davon halte ich von diesen kombinierten Skripten nicht viel. Eine ordentliche URL-Struktur ist langfristig besser.
Bis die Tage,
Matti-
hi,
Wenn man diesen Weg geht, dann aber bitte nichts neues erfinden. Wie wäre es dann mit etwas wie JSON-RPC?
Warum von JSON abhängig machen!? Es gibt auch andere Verpackungsmöglichkeiten für Objekte, womit die Datenübertragung programmiertechnisch völlig transparent wird, so dass Server- wie clientseitig genau dieselben Datenstrukturen vorliegen.
Da würde ich eher sagen, dass mit JSON das Rad neu erfunden wurde und zwar ziemlich umständlich ;)
MfG
-
Warum von JSON abhängig machen!?
Die Frage ist so unangebracht wie »Warum von HTML und CSS abhängig machen?«.
JSON ist *das* Datenformat, um strukturierte Daten an eine clientseitige JavaScript-Umgebung zu übertragen. Natürlich gibt es andere, aber die müsste man selbst implementieren. Dann macht man sich genauso »abhängig« von diesem Format.
Da würde ich eher sagen, dass mit JSON das Rad neu erfunden wurde und zwar ziemlich umständlich ;)
JSON erfindet gar nichts neu, und schon gar nicht umständlich. JSON ist eine Untermenge von JavaScript, kann somit von JavaScript-Entwicklern von Hand geschrieben werden und von JavaScript-Engines direkt als Code gelesen werden (sofern es aus eineer vertrauenswürdigen Quelle stammt). Das Format ist einfach, relativ vielseitig und kompakt. Das gilt für kein anderes verfügbares Format im Browserkontext.
JSON ist mittlerweile Standard für sämtliche einfach zu konsumierenden APIs, Konfigurationen usw. geworden. Es gibt andere mögliche Serialisierungen, aber die passen nicht zu der Umgebung oder sind für die üblichen Aufgaben unnötig komplex und schwierig im Umgang (XML).
Mathias
-
JSON ist mittlerweile Standard für sämtliche einfach zu konsumierenden APIs, Konfigurationen usw. geworden. Es gibt andere mögliche Serialisierungen, aber die passen nicht zu der Umgebung oder sind für die üblichen Aufgaben unnötig komplex und schwierig im Umgang (XML).
Dem stimme ich zu! JSON ist auch bei mir inzwischen längst das Mittel der Wahl wenn ich Daten in programm(iersprache)unabhängigen menschen- und maschinenlesbaren Dateien haben oder übertragen will. Eben weil es auch für sämtliche modernen (und alten wie z.B. Perl) Programmiersprachen (soweit diese das nicht nativ können) fertige Bibliotheken gibt um JSON zu erzeugen oder in "Objekte" einzulesen. XML "war nie wirklich mein Ding".
Zippen, signieren und verschlüsseln kann man es ja außerdem ...
Jörg Reinholz
-
hi,
JSON erfindet gar nichts neu, und schon gar nicht umständlich. JSON ist eine Untermenge von JavaScript, kann somit von JavaScript-Entwicklern von Hand geschrieben werden und von JavaScript-Engines direkt als Code gelesen werden (sofern es aus eineer vertrauenswürdigen Quelle stammt). Das Format ist einfach, relativ vielseitig und kompakt. Das gilt für kein anderes verfügbares Format im Browserkontext.
Du musst mir den JSON nicht erklären ;)
In Hinblick auf die Möglichkeiten moderner Browser mit Binaries umzugehen, gucks Dir doch einfach mal an, wie ich solche Sachen auf meiner Privatseite umsetze, zB. hier und auch das geht demnächst noch einfacher unter Verzicht auf den FileReader weil ich anstelle von ArrayBuffers auch gleich mehrere Blobs in einem POST-Request senden kann, zusammen mit Texten und anderen beliebigen Attributen.
Als kleine Gegenleistung bin ich demnächst öfter mal auf Deinen Seiten wo es um die Organisation von JS-Code geht ;)
MfG
-
Du musst mir den JSON nicht erklären ;)
Wieso machst du dann fragwürdige Aussagen über JSON?
In Hinblick auf die Möglichkeiten moderner Browser mit Binaries umzugehen
Deine Experimente kenne ich, den Zusammenhang mit der Diskussion hier leuchtet mir nicht ein.
JSON ist zur Übertragung von textuellen bzw. textuell serialisierbaren Daten gedacht und dafür gut geeignet. Für Binärdaten gibt es natürlich bessere Formate und ggf. auch bessere Übertragungsprotokolle als HTTP.
Mathias
-
hi,
Deine Experimente kenne ich,
na gottseidank ;)
den Zusammenhang mit der Diskussion hier leuchtet mir nicht ein.
Es hängt alles irgendwie miteinander zusammen, zupf Dir ein Haar aus der Nase und es juckt ganz woanders :)
JSON ist zur Übertragung von textuellen bzw. textuell serialisierbaren Daten gedacht und dafür gut geeignet. Für Binärdaten gibt es natürlich bessere Formate und ggf. auch bessere Übertragungsprotokolle als HTTP.
Ich wäre kein Programmierer, wenn mir auch diesbezüglich nichts einfallen würde, was programmiertechnisch den Unterschied zwischen Text und Binärdaten aufhebt bzw. transparent macht. Diesen Unterschied gibts auch nur, weil sich die Entwicklung in diese Richtung begeben hat, das ist auch gut so und hat seine Richtigkeit (Stichwort Kontext) schafft jedoch andererseits erhebliche Barrieren die gar nicht sein müssen, wenn altbekannte Algorithmen auf der Byte-Ebene konsequent genutzt werden.
Grundsätzlich findet der Transport von Daten per HTTP auf Byte-Ebene statt, egal, ob das Texte sind oder andere Oktetten mit Wertigkeiten von 0..255. Diesem Umstand zollt meine kleine Lib EAV.js und es ist nur ein klitzekleiner Parameter 'raw' welcher das Ding so universell macht:
xhr.responseType = 'arraybuffer';auch bei rein textlichen Geschichten.Btw., den FileReader habe ich jetzt hier rausgenommen, Zeitaufwand: 5 Minuten :)
Und um auf die ursprüngliche Problemstellung zurückzukommen: Diese Anwendung arbeitet nach der alten Schule mit einer zackigen Parameter-Kontrollstruktur wo außer einem Upload mehrerer Image-Binaries auch noch andere Parameter im Spiel sind die allesamt in einer einzigen Klasse gehandled werden. So beinhaltet die Response in der als ArrayBuffer gesendeten Datenstruktur neben der PDF auch ein Feedback-Formular, womit weitere Parameter anfallen, sollte ein Benutzer auf die Idee kommen, da was reinzuschreiben.
Das kann sich sehen lassen, aber Hallo!
-
-
-
-
-
-
-
Hallo,
Durch die vielen unterschiedlichen Requests gibt es nun schon ca. 6 PHP Dateien, für verschiedene DB Abfragen.
Generell ist nichts dagegen zu sagen, dass *verschiedene* Datenbank-Anfragen in *verschiedenen* Dateien gemacht werden. Nur wenn sie inhaltlich zusammenhängen oder immer zusammen auftreten, kann man sie in eine Datei schreiben.
Trenne dich davon, dass URLs eins zu eins auf PHP-Scripte mappen müssen. Das tun sie in keiner größeren PHP-Webanwendung. Die arbeiten meist mit dem MVC-Pattern und »resourceful URLs«. Von welchem PHP-Script eine Anfrage letztlich verarbeitet wird, ist von der URL unabhängig und eine Frage des Routings. Üblicherweise landet eine Anfrage in irgendeinem Controller, der sich aus impliziten Konventionen oder expliziten Routing-Regeln ergibt.
Das mag auf deine Anwendung vielleicht nicht zutreffen, aber ein solches Setup hat sich als sehr flexibel und skalierbar erwiesen.
Würde es eine Möglichkeit geben, nur eine PHP Datei wie "ajax.php" zu nehmen, in der aber unterschiedliche DB Abfragen drin sind?
Es wäre eine sehr schlechte Idee, die Logik für sämtliche Ressourcen, die per XMLHttpRequest angesprochen werden, in einer Datei »ajax.php« unterzubringen. Was im Detail erhoffst du dir davon?
Wenn das Grundproblem ist, dass du in diesen sechs PHP-Dateien Code wiederholst, um die Datenbankabfragen zu machen, dann löse dieses Problem, indem du Code auslagerst und wieder verwendest. Das ist sowohl durch objektorientierte als auch durch prozedurale/funktionale Programmierpattern möglich. Grundlegende Aufgaben wie das Erstellen der Datenbank-Verbindung und das Serialisieren der Antwort als JSON sollten zentral erledigt werden.
Wie aber könnte man dann gezielt die richtige PHP Funktion ansteuern?
So etwas macht man aus verschiedenen Gründen nicht. Die Schnittstelle, die du per HTTP anbietest, sollte nicht eins zu eins auf PHP-Funktionen abbilden. Das bringt einen in große Wartungsprobleme, weil es »Tight Coupling« ist. (So simpel machen es selbst die angesprochenen Remote Procedure Calls nicht.)
Mathias