J4P: Einfache Ajax Funktionalität auf PHP Seite?

[Peter Pippinger (Gast)]

Hallo,

ich wollte euch mal fragen, was ihr von diesem Ansatz haltet, Ajax in 
PHP zu bringen. Dabei würde mich auch interessieren, was man besser 
machen könnte (durchaus auch Präsentation etc...).

http://www.pippinger.com/en/apps-games-2/J4P-micro-ajax.html

Mir persönlich gefällt es eigentlich, Ajax/PHP so zu verwenden, weil man 
die Funktionalität in PHP programmieren kann und m.E. JS und PHP nicht 
vermischt. Da gibt es bestimmt auch andere Ansichten.

Was ich auch sehr nett finde ist, dass man in PHP auch einen großen Teil 
von z.B. jQuery / JS verwenden kann, ohne dass darauf in der 
zugrundeliegenden PHP-Klasse (J4P) speziell darauf eingegangen wird 
("magic-methods").

Vielen Dank auf jeden Fall schon jetzt für konstruktive Kritik und viele 
Grüße,
Peter

[Läubi .. (laeubi)]

Naja, die Idee ist ja nicht neu (siehe z.B. GWT im Java Umfeld), hat 
aber meiner Meinung nach einige gravierende Nachteile:
- Funktionen die du nicht vorgesehen hast kann man von PHP aus nicht 
nutzen
- Man muss eh mit JS klarkommen "erspart" sich also nur auf den ersten 
Blick etwas
- Starke Vermischung von Code und HTLML in deinem Beispiel
- Nun auch noch Vermischung von PHP und JS code
- Wozu überhaupt einen AJAX call? In diesem Beispiel völlig überflüssig

Peter Pippinger schrieb:
> Ajax in PHP zu bringen
"Ajax in PHP" gibt es doch schon, wenn man das wirklich nett machen 
wollte müsste man das meiner Meinung nach Ähnlich wie das Webservice 
Modul aufziehen, auf Server/PHP Seite wird ein Handler registiert, und 
eine JS Lib auf Clientseite mit der man einzelne Funktionen des Handler 
aufrufen kann, dessen Rückgabe wird automatisch in JSON verpackt und auf 
clientseite arbeitet man dann mit den JSON anstelle das man auf 
Serverseite JS generiert.
Das ist dann auch viel flexibler und man kann sowohl Server als auch 
Clientseite bei Bedarf sogar austauschen (hier muss der Client immer 
JS "verstehen" können und zwangsweise JQuery haben, es sei den du baust 
support für andere JS Libs ein).

Ach so: Doku gibt es nur im Download oder muss man sich das aus dem 
Quellcode heraussuchen? Und das ganze JS immer in den Header zu rendern 
ist auch nicht so optimal.

[Peter Pippinger (Gast)]

Hallo Läubi,

danke für Deine Gedanken.

> Naja, die Idee ist ja nicht neu (siehe z.B. GWT im Java Umfeld), hat
> aber meiner Meinung nach einige gravierende Nachteile:
> - Funktionen die du nicht vorgesehen hast kann man von PHP aus nicht
> nutzen
Das verstehe ich nicht ganz, was Du damit meinst.

> - Man muss eh mit JS klarkommen "erspart" sich also nur auf den ersten
> Blick etwas
Mit JS klarkommen stimmt. Da gebe ich Dir Recht. "Ersparen" war nicht 
meine Absicht. Ist glaub ich auch nicht möglich, weil wenn es eine 
Funktionalität ist muss diese Implementiert werden, egal auf welcher 
Seite (Client oder Server).

> - Starke Vermischung von Code und HTLML in deinem Beispiel
Das Beispiel wollte ich eigentlich sehr einfach gestalten, so dass man 
auf einen Blick sehen kann, wie der Aufbau der Seite vorgesehen ist.

> - Nun auch noch Vermischung von PHP und JS code
Da gebe ich Dir Recht. Aber ich finde man hat dadurch auch Vorteile: Ich 
kann die Funktionalität auf der PHP Seite beschreiben und rufe auf 
JS-Client-Seite nur noch diese Funktionen auf. Ich finde gerade in 
solchen Fällen wo man z.B. Datenbank-Bäume Klick für Klick aufbauen 
möchte ist es vom Code her wesentlich übersichtlicher, da Design und PHP 
in diesem Fall nicht so stark vermischt werden. Aber es gibt sicherlich 
auch Fälle wo es umgekehrt ist.

> - Wozu überhaupt einen AJAX call? In diesem Beispiel völlig überflüssig
Naja, das Beispiel soll ein Beispiel sein. Ein einfaches Beispiel, das 
man auf einen Blick ansehen kann. Wenn ich da dann wieder mit DB-Connect 
etc. anfange, dann wird's halt wieder recht umfangreich für ein 
Beispiel. Sollte sowas wie ein Hello World darstellen.

> "Ajax in PHP" gibt es doch schon, wenn man das wirklich nett machen
> wollte müsste man das meiner Meinung nach Ähnlich wie das Webservice
> Modul aufziehen, auf Server/PHP Seite wird ein Handler registiert, und
> eine JS Lib auf Clientseite mit der man einzelne Funktionen des Handler
> aufrufen kann, dessen Rückgabe wird automatisch in JSON verpackt und auf
> clientseite arbeitet man dann mit den JSON anstelle das man auf
> Serverseite JS generiert.
Aber so ähnlich funktioniert es doch, oder?. Die Request Daten werden 
per JSON an PHP geschickt zusammen mit dem Methodennamen, der das Zeug 
auswerten soll, worauf ein Response entsteht, der auf dem Client dann 
ausgeführt wird.

> Ach so: Doku gibt es nur im Download oder muss man sich das aus dem
> Quellcode heraussuchen? Und das ganze JS immer in den Header zu rendern
> ist auch nicht so optimal.
Ja, das mir der Doku ist noch ein Manko. Ich dachte eigentlich, dass das 
Beispiel schon so verständlich ist, dass man was damit anfangen kann, 
weil vielmehr ist es eigentlich dann auch gar nicht.
Habe das auch mal an meinem Kollegen ausprobiert. Er konnte schon nach 
kurzer Zeit etwas damit anfangen.

Viele Grüße,
Peter

[Läubi .. (laeubi)]

Peter Pippinger schrieb:
> Das verstehe ich nicht ganz, was Du damit meinst.

Nehmen wir die Zeile:

J4P::addResponse()->jQuery("body")->css

Ich will jetzt halt nicht css sonder eine andere Funktion aufrufen, 
eventuell sogar von einem Plugin --> geht nicht da im (PHP) Code nicht 
vorgesehen!
Ob man das selber beitragen kann oder was es da ggf. für "raw" 
Funktionen noch gibt kann ich mangels Doku jetzt auf die Schnelle nicht 
beurteilen, aber es sollte so etwa klar sein was gemeint ist :-)

Peter Pippinger schrieb:
> kann die Funktionalität auf der PHP Seite beschreiben und rufe
> auf JS-Client-Seite nur noch diese Funktionen auf
Wie gesagt ich kann der Sache nicht so viel abgewinne, da ich finde der 
Server sollte nur Die Daten liefern und nicht noch präsentationscode 
liefern.
So schreibst du nämlich Servercode der im blödestem Fallen 
ausschließlich mit dieser HTML Seite funktioniert. Änderungen am HTML 
haben dann immer Änderungen am PHP zur folge und die gleiche 
Serverkomponente kann nicht für unterschiedliche Daten hergenommen 
werden.

Peter Pippinger schrieb:
> worauf ein Response entsteht, der auf dem Client
> dann ausgeführt wird.
Gerade das würde ich halt nicht wollen, siehe Anmerkung davor, hier 
mal ein kleines Beispiel:
ajax.php:

<?
class DataHandler {

 public static function fetchRowData($request) {
   //Dummy anstelle DB abfrage...
   switch($request->rowNumber) {
      case 0:
        return array("a", "b", "c");
      case 1:
        return array("Hello World");
      default:
        throw new Exception ("Invalid Row");
   }
 }

J4P::registerFunction("getRow", "DataHandler", "fetchRowData");
J4P::registerFunction(...);
J4P::registerFunction(...);
J4P::handleRequest();
?>

JS:

$(document).ready(function() {
   $(".showRow").click(function(e) {
       var item = $(this);
       var rowNum = item.getAttr("data-row");
       var success = function(data) {
           $.each(data, function(index, val) {
              item.parent().append("<span>"+index+": "+val+"</span>");
           });
       };
       var failure = function(errorCode) {
           alert("Fetching Data failed: "+errorCode);
       };
       $.J4P.call("ajax.php", "getRow", {rowNumber: rowNum}, success, failure);
   });
});

HTML bitte dazu denken (ist hier auch nicht wichtig!). Wie du siehst ist 
jetzt automatisch HTML und PHP nicht mehr so verwoben, das JS kann 
problemlos in eine (cachbare) externe Datei ausgelagert werden, das PHP 
Modul kann universell auf verschiedenen Seiten genutzt werden, mit etwas 
Mühe könnte ich Server oder Client komplett z.B. durch eine Java oder C' 
oder ... Anwendung ersetzen, und der Server muss sich keine Gedanken 
machen wie der Client Code wohl aussähe.

Peter Pippinger schrieb:
> Habe das auch mal an meinem Kollegen ausprobiert. Er konnte schon nach
> kurzer Zeit etwas damit anfangen.

Naja ich fürchte das man bei etwas komplexeren Sachen zu schnell an 
Grenzen stößt und das auf kurz oder lang in einen Spagetti Code 
ausartet. Für kleine Einzelseite sicher nutzbar, im Sinne eine Modularen 
Designs würde ich das als Problematisch ansehen.

[Peter Pippinger (Gast)]

Hallo Läubi

> Nehmen wir die Zeile:J4P::addResponse()->jQuery("body")->cssIch will
> jetzt halt nicht css sonder eine andere Funktion aufrufen,
> eventuell sogar von einem Plugin --> geht nicht da im (PHP) Code nicht
> vorgesehen!

Es gibt nahezu keine "raw Funktionen". Du könntest auf Anhieb auch
J4P::addResponse()->document.getElementById("irgendwas").innerHTML = 
"xxx";
oder
J4P::addResponse()->meineJSFunktion("param1", "param2", "etc");

Es gibt in der Tat Einschränkungen. Du kannst z.B. in PHP einer Funktion 
in diesem Zusammenhang nichts zuweisen. Aber ich denke rein zum Daten 
übertragen, bzw. die ein oder andere Funktion aufzurufen ist es für 
diese geringe Implementierungsgröße von J4P echt sehr vielseitig.

schreiben. Davon weiß J4P nichts. Es wird alles über die magischen 
Methoden __get, __set und __call nach JS "umgebaut". Das finde ich ja 
gerade so interessant und flexibel.

> Ob man das selber beitragen kann oder was es da ggf. für "raw"
> Funktionen noch gibt kann ich mangels Doku jetzt auf die Schnelle nicht
> beurteilen, aber es sollte so etwa klar sein was gemeint ist :-)

Doku wird betimmt noch irgendwann kommen ;-)

> Gerade das würde ich halt nicht wollen, siehe Anmerkung davor, hier
> mal ein kleines Beispiel:
> ajax.php:<?
> class DataHandler {
>
>  public static function fetchRowData($request) {
>    //Dummy anstelle DB abfrage...
>    switch($request->rowNumber) {
>       case 0:
>         return array("a", "b", "c");
>       case 1:
>         return array("Hello World");
>       default:
>         throw new Exception ("Invalid Row");
>    }
>  }
>
> J4P::registerFunction("getRow", "DataHandler", "fetchRowData");
> J4P::registerFunction(...);
> J4P::registerFunction(...);
> J4P::handleRequest();
> ?>JS:$(document).ready(function() {
>    $(".showRow").click(function(e) {
>        var item = $(this);
>        var rowNum = item.getAttr("data-row");
>        var success = function(data) {
>            $.each(data, function(index, val) {
>               item.parent().append("<span>"+index+": "+val+"</span>");
>            });
>        };
>        var failure = function(errorCode) {
>            alert("Fetching Data failed: "+errorCode);
>        };
>        $.J4P.call("ajax.php", "getRow", {rowNumber: rowNum}, success, failure);
>    });
> });HTML bitte dazu denken (ist hier auch nicht wichtig!). Wie du siehst ist
> jetzt automatisch HTML und PHP nicht mehr so verwoben, das JS kann
> problemlos in eine (cachbare) externe Datei ausgelagert werden, das PHP
> Modul kann universell auf verschiedenen Seiten genutzt werden, mit etwas
> Mühe könnte ich Server oder Client komplett z.B. durch eine Java oder C'
> oder ... Anwendung ersetzen, und der Server muss sich keine Gedanken
> machen wie der Client Code wohl aussähe.

Mal ganz abgesehen von dem Beispiel von mir ist das eigentlich im großen 
und Ganzen jetzt doch auch schon so:

Der Include oben inkludiert die Klasse und behandelt den Request.
es weden Funktionen "registriert" indem sie "J4P_" als Prefix haben.
Danach kommt HTML. Hier werde nur noch die PHP Funktionen aufgerufen. Ob 
man hier in der Kommunikation Design mit überträgt bleibt eigentlich 
jedem selbst überlassen. Machen muss man das nicht. Ich denke auch in 
Deinem Beispiel könnte jemand hergehen und Design mit übertragen.

Ich werde eh als Nächstes einen Database-Tree bauen. Dann würde ich hier 
einfach nochmal posten, wie ich mir das vorgestellt habe.

> Naja ich fürchte das man bei etwas komplexeren Sachen zu schnell an
> Grenzen stößt und das auf kurz oder lang in einen Spagetti Code
> ausartet. Für kleine Einzelseite sicher nutzbar, im Sinne eine Modularen
> Designs würde ich das als Problematisch ansehen.

Das sollte mit Disziplin in den Griff zu bekommen sein. Ich denke das 
gilt für jeden anderen Bereich auch.

Aber vielen Dank nochmal für Deine Einschätzung. War echt interessant.

Viele Grüße,
Peter