jQuery-Boom hier im Forum

[suit]

Weil hier im Forum grade so ein jQuery-Boom herrscht - gibts irgendwo eine Statistik zur Verwendung von JavaScript-Frameworks?

Mich würde interessieren, was momentan "vorne" liegt. Google könnte hierzu doch etwas haben - zumindest wie oft welche Library eingebunden wird, sollte sich doch aus deren Daten ermitteln lassen.

[hotti]

Hi,

nur mal so nebenbei: Ich brauche demnächst eine Library, die mir für Ajax-Requests alle Form-Elemente einer HTML-Seite in eine Liste schreibt, die so aussieht:

name=value;vname=vvalue;xname=xvalue;...

optional mit encodeURI, so dass ich die serverseitig so parsen kann, wie ich das gewohnt bin (meistens mit Perl::CGI::param). Ist jQuery sowas?

Horst Schreibfaul

[Kai345]

[latex]Mae  govannen![/latex]

nur mal so nebenbei: Ich brauche demnächst eine Library, die mir für Ajax-Requests alle Form-Elemente einer HTML-Seite in eine Liste schreibt, die so aussieht:

name=value;vname=vvalue;xname=xvalue;...

Ich würde - unabhängig von der Library (da halte ich mich lieber raus, hüstel) - hier eher ein anderes Datenformat vorschlagen: JSON

Cü,

Kai

[hotti]

hi,

nur mal so nebenbei: Ich brauche demnächst eine Library, die mir für Ajax-Requests alle Form-Elemente einer HTML-Seite in eine Liste schreibt, die so aussieht:

name=value;vname=vvalue;xname=xvalue;...

Ich würde - unabhängig von der Library (da halte ich mich lieber raus, hüstel) - hier eher ein anderes Datenformat vorschlagen: JSON

Das wäre ja schon der zweite Schritt. Ich bin jedoch noch an der Stelle, wo ich die Daten einsammeln muss:

var params = ';mdate=' + document.getElementById('mdate').value + ';cdate=' + document.getElementById('cdate').value + ';bc=' + bc + ';ki=' + ki + ';cz=' + document.getElementById('cz').value; // Beispiel

Oder macht das JSON auch?

Hotti

[Kai345]

[latex]Mae  govannen![/latex]

Das wäre ja schon der zweite Schritt. Ich bin jedoch noch an der Stelle, wo ich die Daten einsammeln muss:

var params = ';mdate=' + document.getElementById('mdate').value + ';cdate=' + document.getElementById('cdate').value + ';bc=' + bc + ';ki=' + ki + ';cz=' + document.getElementById('cz').value; // Beispiel

Nein, wenn du die Daten schon zu einer Zeichenkette verknüpft hast, ist es zu spät, dann mußt du die Daten auf der anderen Seite eh wieder „von Hand“ aufdröseln (sofern kein Modul/Funktion existiert), damit wäre der Vorteil von JSON verloren. Ich denke mal, daß es in den Libraries sicherlich Hilfen dazu gibt, keine Ahnung, benutze ja keine. Würde man dein Beispiel nehmen, sähe die „JSONifizierung“ von Hand in Etwa so aus:

var params = {  
  "mdate": document.getElementById('mdate').value,  
  "cdate": document.getElementById('cdate').value,  
  "bc": bc,  
  "ki": ki,  
  "cz": document.getElementById('cz').value  
};

Dies übergibt man dann der Serialisierungs-Funktion und sendet es , auf der Gegenseite wird es wieder entschlüsselt.

Wenn du sicher bist, daß du immer per Perl::CGI::param auftrennen kannst und auch nicht in Gegenrichtung (also zum Client -> JS) senden willst, ist es relativ egal, welches Datenformat du nutzt, da reicht deine Methode sicherlich aus.

Vorteil bei JSON ist, daß man auf diese Art ein unabhängiges und standardisiertes Format hat und auch mal schnell mit einer anderen Programmiersprache die Daten ohne Probleme verarbeiten kann, z.B. auf wenn die Daten auf einem Server verarbeitet werden sollen, der kein Perl bietet. Ist ja alles nur ein Vorschlag.
                                          / \                                            |
Cü,                                        |
                                           |
Kai, der Hammer ---------------------------+

[suit]

Vorteil bei JSON ist, daß man auf diese Art ein unabhängiges und standardisiertes Format hat und auch mal schnell mit einer anderen Programmiersprache die Daten ohne Probleme verarbeiten kann, z.B. auf wenn die Daten auf einem Server verarbeitet werden sollen, der kein Perl bietet. Ist ja alles nur ein Vorschlag.

Es kommt halt immer drauf an, was mit den Daten passiert. In diesem Fall ist es wahrscheinlich Hübsch egal ob man einen beliebigen String zerpflückt, das DOM einer XML-Antwort zerlegt oder JSON verwendet (wobei JSON mit JavaScript wohl am einfachsten weiterzuverarbeiten ist (also direkt).

Wenn es aber um Das tauschen von Seiteninhalten eines XHTML-Dokuments geht - um eben nicht jedes mal die komplette Seite neu zu laden, wenn sich nur ein paar Absätze ändern, halte ich XML aber für das geeignetere Format, weil das ja meistens ohnehin schon vom CMS fast so produziert wird, wie es später gebraucht wird. Da ist es imho unsinnig das Ganze in ein Array zu Verpacken, das in JSON zu konvertieren und dann auf JavaScript-Seiten wieder in ein DOM zu parsen.

[Kai345]

[latex]Mae  govannen![/latex]

Wenn es aber um Das tauschen von Seiteninhalten eines XHTML-Dokuments geht - um eben nicht jedes mal die komplette Seite neu zu laden, wenn sich nur ein paar Absätze ändern, halte ich XML aber für das geeignetere Format, weil das ja meistens ohnehin schon vom CMS fast so produziert wird, wie es später gebraucht wird. Da ist es imho unsinnig das Ganze in ein Array zu Verpacken, das in JSON zu konvertieren und dann auf JavaScript-Seiten wieder in ein DOM zu parsen.

Klar. Ich habe mich hier spezifisch an das gegebene Beispiel gehalten, in dem nur unzusammenhängende Schlüssel-Wert-Paare übergeben werden sollen. Für viele andere Anwendungsfälle halte ich XML ebenfalls für besser geeignet.

Cü,

Kai

[hotti]

moin,

Vorteil bei JSON ist, daß man auf diese Art ein unabhängiges und standardisiertes Format hat und auch mal schnell mit einer anderen Programmiersprache die Daten ohne Probleme verarbeiten kann, z.B. auf wenn die Daten auf einem Server verarbeitet werden sollen, der kein Perl bietet. Ist ja alles nur ein Vorschlag.
                                          / \                                            |
Cü,                                        |
                                           |
Kai, der Hammer ---------------------------+

Auf jeden Fall ;-)

Das guck ich mir mal an heute.

Sch?ne Gr??e,
Horst Drahtzieher

[jobo]

Hallo,

Ich würde - unabhängig von der Library (da halte ich mich lieber raus, hüstel) - hier eher ein anderes Datenformat vorschlagen: JSON

Das ja das, was Zend mit Dojo macht.

Gruß

jobo

[suit]

Das ja das, was Zend mit Dojo macht.

Dojo ist eine Sauerei da es vom Benutzer verlangt, einen bestimmten Code zu haben, weil es eben schon HTML und CSS zur Verfügung stellt - und das ist teilweise etwas unpraktisch.

Einer der Gründe warum ich z.B. nicht mit CSS-Frameworks wie YAML arbeite: den Ballast brauche ich nicht.

Dojo ist im Vergleich zu jQuery imho etwas unsinnig konzipiert und der Browser-Support ist viel schwächer und legt zu viel Focus auf möglichst viele Datenaustauschformate und das zusammenspiel mit der Serverseitigen Komponente. Bei jQuery kann man die Austauschformate per Plugin nachreichen, Built-In ist nur XML/DOM. Bei Dojo hat man gleich 25 verschiedene Formate eingebaut - z.B. ATOM oder RSS, wer braucht sowas in der Core-Funktionalität?

[jobo]

Hallo,

Dojo ist im Vergleich zu jQuery imho etwas unsinnig konzipiert und der Browser-Support ist viel schwächer und legt zu viel Focus auf möglichst viele Datenaustauschformate und das zusammenspiel mit der Serverseitigen Komponente. Bei jQuery kann man die Austauschformate per Plugin nachreichen, Built-In ist nur XML/DOM. Bei Dojo hat man gleich 25 verschiedene Formate eingebaut - z.B. ATOM oder RSS, wer braucht sowas in der Core-Funktionalität?

Ach so, ich las nur "The general rule-of-thumb is: if you are calling a function or class like: dojo.some.randomFunction(), you will need to load the dojo.some module. If you don't, your scripts will throw a "dojo.some not defined" or "dojo.some.randomFunction not defined. There are a few exceptions to this rule, all of which are covered later in this guide."

Zend Framework baut ja scheinbar auf den Datenaustausch via JSON. wie ich schon verlinkte

Gruß

jobo

[suit]

Zend Framework baut ja scheinbar auf den Datenaustausch via JSON. wie ich schon verlinkte

Ich bin XML-Freund - das lässt sich imho wesentlich einfach in ein bestehendes DOM übernehmen. Besonders bei HTML-Dokumenten kann man Teile der Ajax-Antwort schon direkt 1:1 ins DOM hängen.

bei mir sieht das in etwa so aus, für gewönliche Inhaltsseiten:

<data>  
  <page uid="seitenid">  
    <title src="/pfad/zur/grafik-fuer-image-replacement.png">Neuer Seitentitel</title>  
    <subtitle>Neuer Untertitel</subtitle>  
    <navtitle>Neuer Navigationstitel</navtitle>  
  </page>  
  <content>  
    <item col="0"><h3>inhalt in spalte 1</h3><p>bar</p><p>baz</p></item>  
    <item col="0"><h3>inhalt in spalte 1</h3><p>lorem ipsum</p></item>  
    <item col="1"><h3>inhalt in spalte 2</h3><p>lorem ipsum</p></item>  
  </content>  
</data>

Die Daten lässen sich so recht kompakt übertragen und trotzdem relativ einfach ins DOM einhängen da man z.B. aus dem item-Knoten den Inhalt 1:1 als XHMTL übernehmen kann. Warum sollte man hier also einen Umweg über JSON machen?

[jobo]

Hallo,

Ich bin XML-Freund

Naja, ich lese nur immer wieder, dass namhafte Programmierer/Entwickler (Doug Crockford) und Frameworks (Zend) JSON für die Musik der Zukunft halten. Effizienter dacht ich.

• das lässt sich imho wesentlich einfach in ein bestehendes DOM übernehmen.

Echt. Ich hatte mal ein Beispiel aus der ct. Da musste man den XML-Baum durcharbeiten und umwandeln. Das ist doch auch nur eine Aneinanderreihung von Objekten, nur eben nicht in der Javascript Object Notation.

Besonders bei HTML-Dokumenten kann man Teile der Ajax-Antwort schon direkt 1:1 ins DOM hängen.

Ich dachte, das ginge so nicht. Was meinst Du mit 1:1? Als text und dann per innerHTML?

Gruß

jobo

[suit]

Ich dachte, das ginge so nicht. Was meinst Du mit 1:1? Als text und dann per innerHTML?

Mit 1:1 meine ich 1:1 - also einweder Klartext oder direkt das DOM.

Mit .text() oder .html() - was technisch jeweils etwa innerHTML entspricht (einmal escaped und einmal nicht) - werden die geparsten Zeilen dann eingehängt.

Mit jQuery ist das ganze sehr einfach (JSON parsen ist aber auch nicht viel aufwändiger, allerdings kann man dann fertige XHTML-Teile nicht mehr einfach direkt einhängen:

// Request absetzen und XML holen, bei Erfolg an parse_ajax übergeben  
$.ajax({  
  type: 'GET',  
  url: '/foo/bar/?type=10',  
  dataType: 'xml',  
  success: parse_ajax  
});  
  
function parse_ajax(xml) {  
  // das erhaltene XML an jQuery übergeben und das DOM durchsuchen  
  $(xml).find('page>title').each(  
    function() {  
      // das Title-Element suchen und durch den gefundenen Inhalt aus dem XML ersetzen  
      $('title').text($(this).text());  
    }  
  );  
  // das Element mit der ID col0 ausleeren  
  $('#col0').empty();  
  // das XML nach item-Knoten mit dem Attribut col und dem Wert 0 durchsuchen  
  $(xml).find('content>item[col=0]').each(  
    function() {  
      // #col0 selektieren und das gefundene darin anfügen  
      $('#col0').append($(this).html());  
    }  
  );  
}

[suit]

$(xml).find('page>title').each(
    function() {
      // das Title-Element suchen und durch den gefundenen Inhalt aus dem XML ersetzen
      $('title').text($(this).text());
    }
  );

Das war natürlich unnötig kompliziert und geht so auch:
$('title').text($(xml).find('page>title').text());

[tk]

Hallo suit,

Das war natürlich unnötig kompliziert und geht so auch:
$('title').text($(xml).find('page>title').text());

Ich biete noch
  $('title').text($('page>title',xml).text());
:-) Ungetestet, aber JQuery kennt als zweiten Parameter einen Kontext, das sollte also so funktionieren.

Gruß,
Tobias

[suit]

<content>
    <item col="0"><h3>inhalt in spalte 1</h3><p>bar</p><p>baz</p></item>
    <item col="0"><h3>inhalt in spalte 1</h3><p>lorem ipsum</p></item>
    <item col="1"><h3>inhalt in spalte 2</h3><p>lorem ipsum</p></item>
  </content>

Das ist natürlich auch nicht vollständig, da fehlen ein paar CDATA-Bereiche, sonst funzt natürlich nicht :):
    <item col="0"><![CDATA[<h3>inhalt in spalte 1</h3><p>bar</p><p>baz</p>]]></item>
    <item col="0"><![CDATA[<h3>inhalt in spalte 1</h3><p>lorem ipsum</p>]]></item>
    <item col="1"><![CDATA[<h3>inhalt in spalte 2</h3><p>lorem ipsum</p>]]></item>

[Joachim]

Hi,

name=value;vname=vvalue;xname=xvalue;...

dafür gibts eib jquery plugin, das Dir alle formelemente und deren values als array zurückgibt: forms

Gruesse, Joachim

[hotti]

Hi,

name=value;vname=vvalue;xname=xvalue;...
dafür gibts eib jquery plugin, das Dir alle formelemente und deren values als array zurückgibt: forms

Also gut. Neben JSON muss ich wohl oder übel auch noch die Bücher über jQuery lesen. Als ob ich mit dem Alten Testament noch nicht genug zu tun hätte ;-)

Vieße Grüle
Horst Ketzer

[suit]

dafür gibts eib jquery plugin, das Dir alle formelemente und deren values als array zurückgibt: forms

Aas ist nicht notwendig, wenn man serialize() verwendet.

[mario]

name=value;vname=vvalue;xname=xvalue;...

Nimm einfach $("form").serialize()
Das gibt nen dict/hash zurück.

[Peter Nack]

Hi,

auf die Gefahr hin, dass bereits einer die gleiche Antwort gegeben hat (ich habe mir nicht den gesamten Thread durchgelesen):

Ja, JQuery liefert von Haus aus diese Funktionalitaet:
http://docs.jquery.com/Ajax/serialize

In deinem Falle muesstest du dann noch das & durch ; ersetzen.

MfG
Peter