jquery und ajax - Rückgabewert

[equin]

  
$.ajax({  
type: "POST",  
							url: "inc/functions/getYears.php",  
							data: "cntry="+this.id,  
							success: function(msg){  
								alert(msg);  
								$("#select_years").append(msg);  
							}  
						  
						});

[equin]

sorry das sollte ne Vorschau werden... hier nochmal das eigentliche Posting:

Ich hätte mal ne frage zu unten stehendem Code. Ich stelle ja eine Ajax-Anfrage an das Script test.php und alles was ich sort mit echo ausgebe wird dann ja im Rückgabewert "msg" zurückgegeben... kann ich hier beispielsweise auch ein Array zurückgeben?

  
$.ajax({  
type: "POST",  
							url: "test.php",  
							data: "test="+this.id,  
							success: function(msg){  
								alert(msg);  
								  
							}  
						  
						});

[hotti]

hi,

...alles was ich sort mit echo ausgebe wird dann ja im Rückgabewert "msg" zurückgegeben... kann ich hier beispielsweise auch ein Array zurückgeben?

Die Response kommt per HTTP. Da gibt es keine Arrays, sondern nur Text. Du kannst jedoch den Text so strukturieren, dass im DOM ein Array daraus gemacht werden kann.

Hotti

[equin]

und wie genau kann ich das machen?

[EKKi]

Mahlzeit equin,

und wie genau kann ich das machen?

Stichwort: JSON

MfG,
EKKi

[suit]

und wie genau kann ich das machen?

In erster linie solltest du dafür sorgen, dass die "Wurst" die du zurückgibst in einem für jQuery lesbaren Format vorliegt. Bei Ajax ist XML z.B. naheliegend (Content-Type im HTTP-Header nicht vergessen), das kannst du dann gleich als Kontext in der $ auswerten und mit einem Selektor "drüberrumpeln".

dataType sollte dabei auf XML stehen - die Vorgabeeinstellung ist "Räteselraten" ob es jetzt HTML oder XML ist.

[hotti]

und wie genau kann ich das machen?

Ganz genau ;-)

Ja, ne, is klar, bevor ich jemanden zu JSON schicke....

Plan A
Also Du brauchst ein Trennzeichen, ein Zeichen was im Text, im effektiven Inhalt der Response nicht vorkommt.

Wenn die Response z.B. nur aus Zahlen besteht, genügt ein Trennzeichen like '#', um dann im DOM ein Array aus dem Text zu machen.

Plan B
Andere Variante: Sende eine XML-Datei, DOM betrachtet die als Array. Die inneren, eigentliche Werte kannst Du z.B. in Attributen unterbringen. XML ist nur die Verpackung.

Plan C
Ein Anderes Verpackungsmittel ist JSON. Da hast Du richtig Datenstrukturen, die aber auch nur aus Text bestehen. Also geh erstmaal nach Plan A.

Hotti Planer

[suit]

Plan A
Also Du brauchst ein Trennzeichen, ein Zeichen was im Text, im effektiven Inhalt der Response nicht vorkommt.

Wenn die Response z.B. nur aus Zahlen besteht, genügt ein Trennzeichen like '#', um dann im DOM ein Array aus dem Text zu machen.

Ach komm, dass es serialize() hab ich doch schon ein paar mal gesagt

[Kai345]

[latex]Mae  govannen![/latex]

Ja, ne, is klar, bevor ich jemanden zu JSON schicke....

Plan A
Also Du brauchst ein Trennzeichen, ein Zeichen was im Text, im effektiven Inhalt der Response nicht vorkommt.

Wenn die Response z.B. nur aus Zahlen besteht, genügt ein Trennzeichen like '#', um dann im DOM ein Array aus dem Text zu machen.

[...]

Plan C
Ein Anderes Verpackungsmittel ist JSON. Da hast Du richtig Datenstrukturen, die aber auch nur aus Text bestehen. Also geh erstmaal nach Plan A.

Und wenn die Response irgendwann erweitert wird, und das gewählte Trennzeichen dann _doch_ vorkommen kann, fängt man an, den gesamten Quelltext wieder umzuschreiben… Toller Rat.

Cü,

Kai

[suit]

Und wenn die Response irgendwann erweitert wird, und das gewählte Trennzeichen dann _doch_ vorkommen kann, fängt man an, den gesamten Quelltext wieder umzuschreiben… Toller Rat.

Darum dann doch lieber ein entsprechend standardisiertes Format wie eben XML wo die Struktur bereits sauber definiert ist :p

[Pragma]

Und wenn die Response irgendwann erweitert wird, und das gewählte Trennzeichen dann _doch_ vorkommen kann, fängt man an, den gesamten Quelltext wieder umzuschreiben… Toller Rat.

Und er wiederholt ihn unermüdlich immer wieder aufs neue und geht auf die noch noch so gut gemeinten Hinweise nicht ein. Traurig, aber wahr...

[hotti]

h1,

Und wenn die Response irgendwann erweitert wird, und das gewählte Trennzeichen dann _doch_ vorkommen kann, fängt man an, den gesamten Quelltext wieder umzuschreiben… Toller Rat.

Nana, den gesamten Quelltext musst Du nicht umschreiben. Und nichts spricht dagegen, von vornherein ein Trennzeichen zu verwenden, was auch bei späteren Erweiterungen nicht in Texten, nicht in der Eingabe (die wird sowieso gefiltert) und schon gar nicht in der Response vorkommt.

Hotti

[dedlfix]

Hi!

Und wenn die Response irgendwann erweitert wird, und das gewählte Trennzeichen dann _doch_ vorkommen kann, fängt man an, den gesamten Quelltext wieder umzuschreiben… Toller Rat.
Nana, den gesamten Quelltext musst Du nicht umschreiben. Und nichts spricht dagegen, von vornherein ein Trennzeichen zu verwenden, was auch bei späteren Erweiterungen nicht in Texten, nicht in der Eingabe (die wird sowieso gefiltert) und schon gar nicht in der Response vorkommt.

Und Hellseher hotti weiß natürlich, welches Zeichen das sein wird. Wie wäre es mit Escaping? Wenn man das richtig machen will, kann man vom Aufwand her ja gleich JSON nehmen? Natürlich.

Selberlernen ist immer schön und gut, aber wenn man nicht nur zur eigenen Fortbildung etwas erstellen will, kann man auch gleich was in der Praxis erprobtes verwenden.

Lo!

[hotti]

hi,

Und Hellseher hotti weiß natürlich, welches Zeichen das sein wird.

Klar doch. Zeichen zwischen 1 und 30.

Hotti

[Pragma]

Ja, ne, is klar, bevor ich jemanden zu JSON schicke....

Was du dir bis heute noch nicht angesehen hast und trotzdem fleissig Senf dazu produzierst.

Plan A - Selber frickeln

Plan B - XML

Plan C - JSON

Zum Inhalt deiner Pläne sage ich mal nichts, aber die gewählte Reihenfolge beweist meine Eingangsthese.

Hotti Planer

:-(

[hotti]

Ja, ne, is klar, bevor ich jemanden zu JSON schicke....

Was du dir bis heute noch nicht angesehen hast und trotzdem fleissig Senf dazu produzierst.

Quatsch. Natürlich hab ich mir das angesehen. Da wird auch nur mit Wasser gekocht, nur die Töpfe sind größer als in meiner Küche.

Plan A - Selber frickeln

Was heißt hier frickeln!? Selber machen, dabei Lernen!

Plan B - XML

Aufgeblasener Verpackungsmüll.

Zum Inhalt deiner Pläne sage ich mal nichts, aber die gewählte Reihenfolge beweist meine Eingangsthese.

Was für ne These denn?

Hotti

[Pragma]

Quatsch. Natürlich hab ich mir das angesehen. Da wird auch nur mit Wasser gekocht, nur die Töpfe sind größer als in meiner Küche.

Okay! Dann erklär doch mal bitte, warum du den Ansatz JSON für Bloat / überzogen hältst. Er ist simpel(wirklich, ernsthaft, glaub mir doch bitte!) zu handhaben, schlank und sicher.

Plan A - Selber frickeln
Was heißt hier frickeln!? Selber machen, dabei Lernen!

In dem Fall möchte ich sagen: Lernen durch Schmerz!
Nur ein Stichpunkt: Komplexere Datenstrukturen, Erweiterbarkeit.

Plan B - XML
Aufgeblasener Verpackungsmüll.

Wenn auch sehr pauschal formuliert, so bin ich da zumindest beim Einsatzzweck "Serverresponse <-> Browserverarbeitung" bei dir.

Zum Inhalt deiner Pläne sage ich mal nichts, aber die gewählte Reihenfolge beweist meine Eingangsthese.
Was für ne These denn?

Dass du dich bislang noch nicht (ernsthaft, mit Code) mit JSON befasst hast. A, B, C verstand ich als von dir implizierte Komplexitäts-Reihenfolge. Wenn dem nicht so war, ziehe ich den Einwand zurück.

[hotti]

hi,

Dass du dich bislang noch nicht (ernsthaft, mit Code) mit JSON befasst hast.

Ich hab sogar schon Module installiert und dabei nur eins gelernt, dass ich dabei genausowenig von ajax lerne wie ein Publisher mit einem wysiwyg Editor. Also bin ich reingekrochen in der Stoff und hab gesehen, dass ich solche Datenstrukturen auch ohne Module erzeugen kann. Und dann hab ich festgestellt, dass ich auch meine eigenen Datenstrukturen bauen kann, die viel einfacher zu handhaben und durchaus auch scalierbar sind.

Daher meine Empfehlung, gerade für Anfänger, lerne erstmal die Basics.

Hotti

[Pragma]

Ich hab sogar schon Module installiert und dabei nur eins gelernt, dass ich dabei genausowenig von ajax lerne wie ein Publisher mit einem wysiwyg Editor.

Äpfel? Birnen?

Und dann hab ich festgestellt, dass ich auch meine eigenen Datenstrukturen bauen kann, die viel einfacher zu handhaben und durchaus auch scalierbar sind.

Einfacher als mit JSON und dennoch skalierbar? Also doch: You never tried it... Falls doch, zeig doch bitte mal deinen Perl-Code zum Wikipedia Beispiel

Daher meine Empfehlung, gerade für Anfänger, lerne erstmal die Basics.

Da ist was dran, ohne Betrachtung der Aufgabenstellung aber wertlos.

Sowas wie Apache verwendest du schon, oder baust du dir auch eigene Webserver? Verwendest du eine Template Engine? DBI Module? CGI Modul?

print join($dc, @array); # $dc Delimiter Character

Pfft! Warum join? Das kann ich mir doch auch selber schreiben!

Jetzt schau außerdem mal, wie das mit JSON aussehen kann:
print to_json(@array);

@array kann dann im Unterschied zu join allerdings komplexe Datenstrukturen beherbergen.

[hotti]

hi,

Einfacher als mit JSON und dennoch skalierbar? Also doch: You never tried it... Falls doch, zeig doch bitte mal deinen Perl-Code zum Wikipedia Beispiel

Sagt Du mir erstmal, wozu ich JSON brauche für das bischen Text ;-)

Btw., Routinen für URL-Encoding, URI::Escape, maskieren von Zeichen usw., das nutzt JSON auch. Dafür gibts fertige Libs in Perl. Und fürs DOM gibts encodeURI, decodeURI, URIComponent... Alles schon da. Das erfinde ich genausowenig neu wie Webserver und Protokolle. Ich nutze das nur, genauso wie JSON das nutzt.

Hier ein Beispiel, wie ich Ajax umsetze. Das Script funktioniert auch ohne Ajax:

http://rolfrost.de/cgi-bin/mayacorr.cgi

CGI.pm: Ja es gibt Spezialfälle, da verzichte ich auf das Modul und lese STDIN selbst aus um an POST Daten zu kommen. Deswegen erfinde ich das Rad trotzdem nicht neu.

jQUERY: 150 kB extra zum Client schicken um ein paar Formularfelder zu füllen? Na ick weeß ja nich. Serialize? Das ist bei mir genauso eine Codezeile wie mit jQuery, ervntl. ein bischen länger.

So, und jetzt lass mich weiter arbeiten, ich hab noch zu tun ;-)

PS: Frag mal den equin für was er ein Array braucht.

Hotti

PS s.o.

[Pragma]

Du antwortest oft nur so, wie es dir grad in den Kram passt, lässt die wichtigen Stellen einfach aus und kommst bewusst oder unbewusst vom Thema ab. Nicht nett!

jQUERY: 150 kB extra zum Client schicken um ein paar Formularfelder zu füllen? Na ick weeß ja nich. Serialize? Das ist bei mir genauso eine Codezeile wie mit jQuery, ervntl. ein bischen länger.

Und nochmal: You never tried it - sonst wüsstest du, dass jQuery mitnichten notwendig ist, um JSON zu verarbeiten. Verzeih mir den Hinweis auf einen bekannten Comedian: Wenn man keine Ahnung hat, dann einfach mal....

So, und jetzt lass mich weiter arbeiten, ich hab noch zu tun ;-)
PS: Frag mal den equin für was er ein Array braucht.

:-(

[hotti]

moin,

Und nochmal: You never tried it - sonst wüsstest du, dass jQuery mitnichten notwendig ist, um JSON zu verarbeiten.

Und nochmal: Das ist mir sehr wohl bekannt.

Zurück zum Thema: mit JSON & Co ist es möglich, Datenstrukturen in einer Textresponse zu übertragen und ins DOM einzubauen. Das kann ich auch mit eigenen, schlankeren (!) Routinen erledigen, ohne dazu die Standards neu erfinden zu müssen.

Die Standards dazu stehen in einschlägigen RFCs, z.B. das URI-Encoding, früher hieß das Escape. Dazu gehören auch standardisiert festgelegte Zeichen, mit denen eine Datenstruktur in eine Parameterliste verwandelt werden kann:

name=Albers&vname=Hans&Wohnort=Hamburg

Und wenn Hans nach München umzieht, steht da eben M%C3%BCnchen, wenn es UTF-8-codiert ist.

Und wenn der Parameter hobbies dazu kommt, steht da

hobbies=Radfahren%3BSchwimmen%3BWandern

sofern die _eigene_ Liste den ';' Punktstrich als Delimiter hat, die _ich_ auch anders festlegen könnte.

Das ist alles Schnee von gestern, da bringt auch JSON nix Neues und schon gar nichts was das Internet revolutioniert. Außer einer dickwandigen Kiste, um das Bischen Schnee einzupacken ;-)

Und dann haben wir noch das DOM auf der anderen, der Empfängerseite. Da gibt es auch schon fix und fertige Routinen wie split() und decodeURIComponent() womit obenstehende Liste wieder fachgerecht in die Einzelteile zerlegt werden kann. Da brauche ich keine extra 150 kB, die ich dem Client schicken muss, um das ins DOM einzubauen.

Der Hüftschwung, den ich machen musste, bestand einfach nur darin, zu begreifen, dass ein URI-Encoding nicht nur auf das Senden vom UA zum Webserver beschränkt ist, sondern dass das genausogut auch andersherum geht, und dass ich, um das Anzuwenden, nicht das Rad neu erfinden muss.

Und nochmal: Bei JSON wird auch nur mit Wasser gekocht, nuhr: Die Töpfe sind da größer als meine.

Viele Grüße,
Rolf

PS: Danke Dir, danke Forum

[dedlfix]

Hi!

Zurück zum Thema: mit JSON & Co ist es möglich, Datenstrukturen in einer Textresponse zu übertragen und ins DOM einzubauen. Das kann ich auch mit eigenen, schlankeren (!) Routinen erledigen, ohne dazu die Standards neu erfinden zu müssen.

Ja, das ist immer so. Wenn man Äpfel mit Obst vergleicht, ist Äpfel auf den ersten Blick das einfachere Ergebnis. Obst ist komplexer, aber flexibler verwendbar. Das Grundprinzip ist bei beiden gleich, erst wachsen lassen, dann essen. Wenn man es verwendet, muss man das richtig tun, sonst bekommt man unter Umständen Probleme. Äpfel kann so essen, anderes Obst muss man schälen und so weiter. Beim Obst-Anbieter haben bereits viele Augen das Prinzip in der Praxis erprobt. Es ist soweit gereift, dass man es einfach kaufen und verwenden kann. Bei der eigenen Apfelsorte und noch dazu bei wenig Erfahrung besteht die Chance, Fehler zu machen, die die Obst-Gemeinschaft schon erfolgreich verbannt hat. Zudem muss man den Apfelbaum erst wachsen lassen und gelegentlich pflegen.

Hier muss jeder selbst entscheiden, was er will. Weitreichende Erfahrungen mit Äpfeln sammeln, die man später vielleicht auf andere komplexere "Öbste" anwenden kann, aber auch neue dazulernen muss. Oder man konzentriert sich auf sein eigentliches Geschäft und nimmt erprobtes Fertig-Obst dazu.

Lo!

[Struppi]

Und dann haben wir noch das DOM auf der anderen, der Empfängerseite. Da gibt es auch schon fix und fertige Routinen wie split() und decodeURIComponent() womit obenstehende Liste wieder fachgerecht in die Einzelteile zerlegt werden kann. Da brauche ich keine extra 150 kB, die ich dem Client schicken muss, um das ins DOM einzubauen.

auf der Empfängerseite braucht JSON nur ein eval()

Und eine Bemerkung am Rande, du baust in deine CGI Skripte, in jede Datei 250KB ein (use CGI), nur um eine Funktion zu nutzen, ist das sinnvoller?

Struppi.

[hotti]

h1,

auf der Empfängerseite braucht JSON nur ein eval()

Du meinst: devil ;-)

Na egal, guck mal hier: http://rolfrost.de/cgi-bin/alib.cgi

Einen Blick in den Quelltext nicht vergessen...

Und eine Bemerkung am Rande, du baust in deine CGI Skripte, in jede Datei 250KB ein (use CGI), nur um eine Funktion zu nutzen, ist das sinnvoller?

Ja, aber auf dem Server. Und damit siehts dann so aus in der Kontrollstruktur:

  
if(param('ajax')){  
	# URI zusammenbauen, Struktur: name=value&name=value like GET  
	# Die Values mit uri_escape  
	my @data = ();  
	foreach my $pname(param()){  
		push @data, $pname."=".uri_escape(param($pname));  
	}  
	print join("&", @data);  
}  
else{  
	print htmlUp('Datenstrukturen in Ajax-Response'), form(), htmlDown;  
}  
  

Viel Spaß damit;
Horst Deppendorff

[Struppi]

auf der Empfängerseite braucht JSON nur ein eval()

Du meinst: devil ;-)

Gegen eval gibt es nichts zu sagen, wenn es vernüftig eingesetzt wird. In Perl verwendet man ja auch oft eval um z.b. Exceptions zu fangen.

Einen Blick in den Quelltext nicht vergessen...

Mir ist schon klar, dass eine einfache Datenstruktur leichter ohne Hilfsmittel vearbeitet werden kann. Aber gerade dir als Perler müßte auch klar sein, dass der Einsatz von Bibliotheken zur Arbeit dazu gehört. Sicher könnte man in einem einfachen Skript auch auf DBI verzichten oder GD, was du aber hoffentlich nicht tust.

Und eine Bemerkung am Rande, du baust in deine CGI Skripte, in jede Datei 250KB ein (use CGI), nur um eine Funktion zu nutzen, ist das sinnvoller?

Ja, aber auf dem Server.

Und? Du hast als Argument gegen JSON eingeführt, man bräuchte 150KB (was nicht stimmt) und gleichzeitig lädst du ständig mehr als 250KB um eine winzige Funktion zu nutzen und schreibst Funktionen in dein Skript, die in dem Modul schon vorhanden sind. Du prangerst also Verschwendung an und verschwendest im gleichen Atemzug selber.

Struppi.

[hotti]

h1,

Und? Du hast als Argument gegen JSON eingeführt, man bräuchte 150KB (was nicht stimmt)

Ich meinte jQuery.

Tschüss,
  Hotti

[Struppi]

Und? Du hast als Argument gegen JSON eingeführt, man bräuchte 150KB (was nicht stimmt)

Ich meinte jQuery.

Das Wissen wir, aber du brauchst kein jquery um mit JSON zu arbeiten. Und mein Hauptargument war auch nicht ob JSON sinnvoll ist oder nicht, sondern dass du hier einerseits etwas überflüssiges siehst, bei CGI.pm in einem größeren Umfang aber nicht.

Struppi.

[Pragma]

You never tried it - sonst wüsstest du, dass jQuery mitnichten notwendig ist, um JSON zu verarbeiten.
Und nochmal: Das ist mir sehr wohl bekannt.

Warum führst du dann die 150kb jQuery als Argument an?!

Zurück zum Thema:

Ja, bitte! Zur Erinnerung: SERVER <> CLIENT Datenaustausch - Selbstgebeastelt vs. JSON.

mit JSON & Co ist es möglich, Datenstrukturen in einer Textresponse zu übertragen

Stimmt, wobei ich "& Co" mal bewusst überlese.

und ins DOM einzubauen.

Falsch! Das hat mit JSON nichts zu tun! Ob und wie du das DOM manipulierst, ist eine gänzlich andere Fragestellung.

Das kann ich auch mit eigenen, schlankeren (!) Routinen erledigen

Wir drehen uns im Kreis. Die Behauptung hast du bereits mehrfach aufgestellt, bist aber z.B. deinen schlankeren Lösungsweg für das genannte Wikipedia-Beispiel schuldig geblieben. Nochmal:

... [Deine Ausführungen über Escaping, UTF-8, Dom] ...

Was hat das mit dem Thema zu tun?

[suit]

Was heißt hier frickeln!? Selber machen, dabei Lernen!

Selber lernen ist kein Fehler, aber nicht in diesem Kontext.

Aufgeblasener Verpackungsmüll.

Kommt drauf an, wie kompliziert man es sich macht:

<r>  
 <a v="foo" />  
 <b v="bar" />  
 <c v="baz" />  
</r>

a=foo;b=bar;c=baz ist zwar kürzer, aber spätestens wenn du = oder ; als Nutzinhalt verwenden musst wirds dich aufstellen.

[hotti]

hi,

a=foo;b=bar;c=baz ist zwar kürzer, aber spätestens wenn du = oder ; als Nutzinhalt verwenden musst wirds dich aufstellen.

Du bist auf dem richtigen Weg ;-)
Noch kürzer ist: foo\0bar\0baz

Mit Perl geht das Ratzfatz:
print join($dc, @array); # $dc Delimiter Character

Btw., wenn Du in einem URL bestimmte Zeichen wie z.B. das &, verwenden willst, musst Du es auch encoden.

Hotti

[suit]

Du bist auf dem richtigen Weg ;-)
Noch kürzer ist: foo\0bar\0baz

aha, und du vernichtest damit information "a", "b" und "c" ist ggf. relevant.