Ajax mit Contenido nutzen

[projumper]

Hallo @ all,

ich habe mal eine Frage:

Gibt es irgend etwas vorbereitetes in Contenido für Ajax? API's, .... . Oder kennt jemand ein Tutorial, wo man sich belesen kann wie man Ajax mit Contenido benutzen könnte?

Wenn es sowas nicht gibt, dann eventuell Anleitungen wie man die freien Ajax Frameworks in das Contenido einbinden könnte?

vielen Dank im Voraus.

projumper

[Oldperl]

Hallo projumper,

Gibt es irgend etwas vorbereitetes in Contenido für Ajax? API's, ....

Nein, nur rudimentär für das Backend im Bereich Kategorien. Diese Schnittstelle wird aber IMO auch nicht so bleiben wie sie ist, und ist im Moment, so wie sie sich darstellt, auch nicht für Usererweiterungen gedacht.

Oder kennt jemand ein Tutorial, wo man sich belesen kann wie man Ajax mit Contenido benutzen könnte?

Ein direktes TuT dafür gibt es nicht, weder für BE noch FE. Jedoch kann ich mich erinnern schon ein paar Module hier im Forum gesehen zu haben, die z.B. jQuery oder ähnliche Frameworks (FW) einsetzen.

Wenn es sowas nicht gibt, dann eventuell Anleitungen wie man die freien Ajax Frameworks in das Contenido einbinden könnte?

Eigentlich doch wie auch bei einer stinknormalen HTML-Seite. Javascript-Bibliotheken im Head der Seite einbinden (Layout) und dann die Funktionalitäten des Framework z.B. im Body (Modulen) nutzen.

Richtet sich natürlich jeweils nach dem FW welches man einsetzt, kann man aber immer in der jeweiligen Doku nachlesen und ist grundsätzlich erst einmal nicht von Contenido abhängig.

Gruß aus Franken

Ortwin

[projumper]

besten Dank für die Antwort. Werde mich mal auf das Ajax + Contenido stürzen.....

projumper

[kummer]

eine anmerkung am rande:

damit du ajax mit contenido verwenden kannst, musst du die ausgabepufferung (ob_start() und ob_end_flush()) verwenden. sonst ist es nämlich nicht möglich, aus einem modul heraus einen gültigen response (z.b. json) vorzunehmen.

[idea-tec]

das kommt ganz aufs framework an und was getan werden soll

[kummer]

das kommt ganz aufs framework an und was getan werden soll

ne, da spielt das framework keine rolle. reines javascript läuft freilich auch so. bloss ist es dann halt kein ajax (asynchronous javascript and xml) mehr. denn dafür ist stets kommunikation mit dem server erforderlich. und auch wenn dieser im einzelfall html ausgeben soll, ist nie die ausgabe von header und body gefragt, sondern reiner html-content. nebenbei bemerkt wird in den meisten fällen json oder eben xml übertragen. in diesen fällen darf dann gar kein html mehr vorkommen.

deshalb sollte zulnächst in der front_content.php mit ob_start() die ausgabepufferung eingeschaltet werden und am ende (unmittelbar nach page_close()) die ausgabepufferung mit ob_end_flush() beendet und der puffer an die standardausgabe gesendet werden. dann kannst du in dem modul, welches auf den ajax-request reagiert mit ob_end_clean() zunächst die pufferung stoppen und den puffer verwerfen. mit header wird anschliessend ein im einzelfall gültiger header gesendet, das modul macht seine ausgabe und beendet die weitere ausführung mit exit(0).

[Oldperl]

eine anmerkung am rande:

damit du ajax mit contenido verwenden kannst, musst du die ausgabepufferung (ob_start() und ob_end_flush()) verwenden. sonst ist es nämlich nicht möglich, aus einem modul heraus einen gültigen response (z.b. json) vorzunehmen.

Nein, sollte man nur, wenn man per HTTPRequest den gleichen Artikel aufruft und vom Modul eine Antwort erwartet (html oder xml). Dann kann man dieses Vorgehen anwenden.
Verwendet man eine zusätzliche Datei um AJAX-Anfragen zu bearbeiten, benötigt man keine Pufferung.

Auch hier gilt wie so oft der Satz "Viele Wege führen nach Rom".

Gruß aus Franken

Ortwin

[idea-tec]

ich wollte unserem "Master" nicht widersprechen ... schön, dass es ein anderer getan hat
außerdem wäre das am ende offtopic gewesen

[kummer]

Auch hier gilt wie so oft der Satz "Viele Wege führen nach Rom".

wenn auch einer länger ist als der andere. bei einer trennung kann das modul nicht alle aufgaben übernehmen. das wiederum bedeutet, dass du ein weiteres layout und ein weiteres template machst, welches sich ausschliesslich um ajax-requests kümmert. aber das ist freilich auch möglich. eine pufferung hat indes kaum nachteile. insbesondere möchte ich zu bedenken geben, dass bei ersten aufruf eine injektion mit ajax in der regel keinen sinn macht, da ja bereits die richtigen werte im quelltext übertragen werden können. erst darauf folgende requests machen mit ajax sinn. dann muss man sich das konzept einmal genauer anschauen: je mehr verschiedene dateien angesprochen werden, desto mehr entfernt man sich vom ziel einer mvc-umsetzung.

addon: eine antwort vom server ist bei anwendung von ajax im übrigen normal. und sollen die für den artikel spezifischen werte verwendet werden, dann ist der überhang durch contenido letztlich unvermeidlich.

[Oldperl]

Sorry, aber ich habe keine Lust auf diese Grundsatzdiskussionen.
Auch helfen sie projumper oder anderen Usern, die das lesen, wahrscheinlich erst mal recht wenig. Sie gehören wohl eher in den Dev-Bereich.
Alles Gesagte ist für sich und im speziellen Anwendungsfall wohl richtig, aber nicht die alleinige Wahrheit oder der alleinige Weg zum Ziel.

Wie gesagt, "Viele Wege führen nach Rom"!

Gruß aus Franken

Ortwin

[projumper]

Hallo @ all,

ich habe AJAX ohne weitere Problem in das Contenido reinbekommen. An sich war das ganz einfach reines JavaScript.

An einer Stelle hatte ich jedoch ein problem mit dem Ausgabepuffer. Der Ajax Request ging an front_content.php mit POST variablen , bla bla bla.

Geliefert habe ich bekommen natürlcih die ganze Seite!

Ich habe aber leider nur das extra dafür angelegte Modul-Template gebraucht, natürlcih sollte dieses Modul-Template vorher mit den richtigen Werten aus der DB bestückt werden.

also war meine Lösung zu erst folgende:

Code: Alles auswählen

switch($_POST['state']){

  case 'link':
    
    $id = $_POST['id'];
   
    ob_clean(); //puffer leeren
    
   
    echo "<img src=\"".$bild."\"/>"; //könnte man ins Template auslagern
    
    ob_end_flush(); //puffer ausgeben
    
    break;

  default:
 .......

Leider kamm immer noch der Rest der Seite mit. In meinem Fall der Footer.

Deswegen mein zweiter ansatz mit:

Code: Alles auswählen

switch($_POST['state']){

  case 'link':
    
    $id = $_POST['id'];
   
    ob_clean(); //puffer leeren
    
   
    echo "<img src=\"".$bild."\"/>"; //könnte man ins Template auslagern
    
    ob_end_flush(); //puffer ausgeben
    
     die(); //ANHALTEN

    break;

  default:
 .......

Jetzt funktioniert das perfekt!

Die Frage ist jetzt nur ist das eine elegante Variante? Das Script so anzuhalten?

mfg

projumper

[kummer]

das break brauchst du dann eigentlich nicht mehr. und ich würde auch nicht die() verwenden, sondern exit(0). das macht zwar das gleiche; aber die() hat mehr den charakter eines abbruchs mit fehler, während exit(0) ein gewünschter, gewissermassen ordentlicher abbruch darstellt. in der ausführung sind beide varianten jedoch weitgehend identisch.

ich hätte jetzt den buffer gleich mit ob_end_clean() gelöscht und verworfen und anschliessend die ausgabe aus deinem modul vorgenommen. sobald klar ist, dass dein modul alleine eine ausgabe vornehmen wird, wird der puffer gar nicht mehr benötigt und kann deshalb ausgeschaltet werden.

die frage der eleganz stellt sich so eigentlich nicht. du hat nur noch die wahl, gleich - wie es ortwin vorgeschlagen hat - mit einem weiteren script vorzunehmen. willst du die funktionen von contenido nutzen, ist der durch contendio entstehende überhang unvermeidlich. dann bleiben noch die module, die vorher ausgeführt werden. deren ausführungsdauer ist in der regel jedoch klein im vergleich zu dem, was contenido im hintergrund macht. insofern würde ich das für eine gute lösung halten.