Ajax-Framework für .Net

Hier zur Meldung:
www.heise.de/newsticker/meldung/84222
Und hier zum Downloaden:
ajax.asp.net/
Hoffe es gibt irgendwann mal nen ordentliches Framework für Python in dieser Richtung (wenns es schon gibt wäre ich fürn link dankbar)

ajaxian.com/by/topic/python/

Ich finde im allgemeinen wird eine wenig zu viel Wind um diesen Ajax-Hype gemacht. Als ich mich hinsetzte, um das zu erlernen und mal probemäßig etwas "in Ajax" zu coden, musste ich ernüchtert feststellen, dass sich eigentlich alles um die Möglichkeit drehte, per Javascript im Hintergrund einen request zu senden, was zudem nicht neu ist, da es auch - zugegebenermaßen weniger elegant - mit einem unsichtbaren Frame möglich ist und so auch schon seit den 90igern praktiziert wird. Jetzt ist es halt in, Nutzdaten per xml auszutauschen, oder eben viel einfacher (und von meiner wenigkeit empfohlen), dieses über json (javascript object notation) zu tun, weil man das mit 2 php-funktionen unter dach und fach hat und es in javascript ja schon fertige Objekte darstellt (eval und zack). Im Prinzip konnte ich aber an Ajax nichts neues entdecken.
Natürlich ist das XMLHttpRequest Objekt von Nutzen, und ich setze es bei meinem Spiel nun auch ein. Es anzuwenden bedarf aber nicht mehr Einsatz als das erlernen oder besser kennenlernen einer neuen PHP-Funktion - vielmehr ist etwas Javascript Kenntnis von Nöten - und das ist aber nicht erst seit Ajax so, wenn es um clientgesteuerte dynamische Inhalte geht.
Klar ist es jetzt leichter, nur jene Daten zu erfragen, die man tatsächlich benötigt, ein Ajax-Request erleichtert die Sache sehr. Die DOM-Manipulation per Javascript aber ändert sich dadurch nicht - weshalb ich hier ein Framework brauchen sollte, ist mir nicht klar. Begriffe wie Ajax und vor allem Web2.0 sind eigentlich mehr Modebegriffe als technologische Innovationen. Man unterschätzt das Web der Pionierzeiten.
Klärt mich auf wenn ich etwas übersehen habe.

Meiner Meinung nach ist ein Framework nicht nur auf Clientseite tätig, sondern vorallem auf der Serverseite. Sicherlich ist diese eigentliche Requestschiene, die mittels dem XmlHttpRequest passiert nur ein Bruchteil von dem, was dann noch an Arbeit nötig ist (ausser man schickt kompletten Html-Text, was aber nicht der Sinn ist).
Auch biete meiner Meinung nach ein Framework eben auch vorgefertigte Funktionen, die man auch zur Arbeit an der DOM selbst, nutzen kann und nicht immer das Rad neu erfinden muss.
Sicher ists gehypt, dass wollt ich damit auch net sagen, aber man sollte haltschon bescheid wissen. Ist ja immer so ne Sache, ob man es nun will. Ich würde keine Web-Anwendung entwickeln wollen und dann gleich dabei sagen: Ja unbedingt mittels AJAX. Es gibt einige Vor- und Nachteile. Wollte eigentlich nur ne Info geben, dass da Microsoft was rausgebracht hat

Original von KoMtuR
Meiner Meinung nach ist ein Framework nicht nur auf Clientseite tätig, sondern vorallem auf der Serverseite. Sicherlich ist diese eigentliche Requestschiene, die mittels dem XmlHttpRequest passiert nur ein Bruchteil von dem, was dann noch an Arbeit nötig ist (ausser man schickt kompletten Html-Text, was aber nicht der Sinn ist).
Auch biete meiner Meinung nach ein Framework eben auch vorgefertigte Funktionen, die man auch zur Arbeit an der DOM selbst, nutzen kann und nicht immer das Rad neu erfinden muss.

Also wenn du in json verschickst, ist php-seitig ein Funktionsaufruf bei Empfang und einer bei Versand von Nöten (json_decode, json_encode), auf Javascript-seite ist nicht mehr von nöten, also was es auch ohne Ajax war, DOM-Manipulation gibt es ja nicht erst seit Ajax. Der Name Ajax-Framework ist daher wie ich finde irreführend. Ajax ist nur ein kleiner Teil dessen und der einzig neue an der Sache. Mag sein, dass mit der nun einfachen Möglichkeit des Request Absetzen viele Ideen entstanden sind für neue Gadgets, und diese nun in frameworks implementiert werden und daher Ajax-Frameworks heissen, weil die Entstehung von Ajax diese Ideen eben begünstigt hat - neu ist das aber nicht.
Na ja, ich weiß, was du sagen willst, hast ja auch recht. Ich möchte halt ergänzen, dass hier nicht unbedingt ein Framework nötig ist, sondern dass es wie ich glaube genauso lange dauert, sich in diese Frameworks einzuarbeiten, wie das, was man selbst braucht, einfach selbst zu implementieren - weil es eben kein Hexenwerk ist. Ich habe mir prototype, script.aculo.us und wie sie heißen angesehen, bis ich da durchgeschnallt habe...Also habe ich mir Ajax for noobs Tutorials angesehen, Javascript kann ich schon - ruck zuck konnte ich das was ich brauchte selbst machen.
Daher möchte ich potentielle Nachahmer einfach ermutigen.

Original von riki1512
[Der Name Ajax-Framework ist daher wie ich finde irreführend. Ajax ist nur ein kleiner Teil dessen und der einzig neue an der Sache.

Ich gebe Dir in sofern recht, dass der Begriff Ajax etwas irreführend ist, da Ajax ja eigentlich nur den Transportmechanismus beschreibt. Aber im "allgemeinem" Sprachgebrauch, steht Ajax halt auch für die Einsatzgebiete.
Der Begriff Framework ist hingegen schon richtig. Client-seitig liefern die Frameworks fertige Funktionen. Ob es nun leichter ist, sich in Prototype einzuarbeiten oder es gleich selbst zu machen, ist vermutlich Geschmackssache, wobei die fertigen Frameworks den Vorteil haben, eine hohe Browserkompatibilität zu haben.
Die Server-seitigen Frameworks hingegen sind wieder eine ganz andere Geschichte. Ich weiß nicht, wie MS das bei seinem Framework gemacht hat, aber in Rails ist es z.B. so, dass dort Prototype genutzt wird und die Funktionen aus dem Framework durch Ruby-Funktionen gekapselt wurden. Man braucht also eigentlich gar keine JavaScript und Ajax Kenntnisse, um es zu nutzen. Das ganze hat Rails mir RJS dann noch einen Schritt weiter geführt und eine Template-Engine geschaffen, die Ruby-Code in JavaScript umsetzt.
Das finde ich eigentlich eine ganze schöne Geschichte, da ich JavaScript hasse, wie die Pest. Aber ich brauche nicht auf die "schicken" Web2.0 Features verzichten und kann alles in der mir bekannten Sprache entwickeln.

Original von Agmemon
...aber in Rails ist es z.B. so, dass dort Prototype genutzt wird und die Funktionen aus dem Framework durch Ruby-Funktionen gekapselt wurden. Man braucht also eigentlich gar keine JavaScript und Ajax Kenntnisse, um es zu nutzen. Das ganze hat Rails mir RJS dann noch einen Schritt weiter geführt und eine Template-Engine geschaffen, die Ruby-Code in JavaScript umsetzt.

Das ist natürlich eine feine Sache.

Das finde ich eigentlich eine ganze schöne Geschichte, da ich JavaScript hasse, wie die Pest. Aber ich brauche nicht auf die "schicken" Web2.0 Features verzichten und kann alles in der mir bekannten Sprache entwickeln.

Ich hasse Javascript nur, weil es nicht überall gleich läuft. Nee, eigentlich hasse ich Microsoft, weil in Mozilla und Konqueror tuts immer wie es soll, aber wäre ja zu leicht, wenn Billy nicht wieder seine antistandards durchsetzen würde. Javascript finde ich halt - lustig, ich meine drag&drop im Browser, Dynamik und so, kann schon Spaß machen. Ich mache da mehr exotische Sachen, die kann man mit einem Framework glaube ich nicht so leicht totschlagen. Wollte auch nicht generell Frameworks schlechtreden (jeder der keines benutzt hat ja sein eigenes - ohne kommt man ja kaum aus), ich wollte nur an dem Namen Ajax-Framework konstruktiv Kritik ansetzen. Oder halt die Jungprogrammierer daran erinnern, dass Ajax kein Hexenwerk ist und man für Kleinigkeiten nicht mit Kanonen auf Spatzen schießen muss.
Wenn man nach und nach Dinge selbst implementiert, die man da braucht und dabei alles ziemlich allgemein/abstrakt hält hat man nach einer Weile ja seine eigene kleine Klassensammlung (und hat noch einiges gelernt). Aber klar, Ansichtssache, ist sicherlich kein Fehler mühsam den Einstieg in ein populäres Framework zu finden und da dann dafür später irgendwann voll durchzusteigen.

Naja ich wollte sicherlich niemand fehlleiten in seiner Entscheidung Ich wollte nur mal informieren.
Man sollte sich ja nicht gleich mittels XmlHttpRequest als Framework anfangen, so dass man von der Materie nichts mitbekommt. Sicher ne einfache Entscheidung, aber solange man nicht die Gegebenheiten gesehen hat sollte man nicht die Möglichkeiten nutzen. Sicher ist das nur mein Standpunkt und ich würde mich sicherlich auch nicht auf Hardwareebene wagen, nur um die Tastatur anzusprechen. Aber ich denke Ajax ist da nicht so niedrig angelegt und sehr leicht verständlich

Ich habe mir das Toolkit mal heruntergeladen und werde in den nächsten Wochen mal mein Spiel mit eins, zwei Add-Ons beglücken. Mal schauen, was man daraus machen kann und wie kompatibel dies mit anderen Browsern ist (insbesondere Opera).

Jo Praxisberichte wären schon toll. Mal schauen wie Microsoft so gearbeitet hat

Habe mir mal das Framework angetan und muss sagen:
Ich bin recht begeistert.
Die Installation und die Einrichtung in das Visual Studio ist nicht gerade ein einfaches 'Weiter >>'-Klicken, aber die Tutorials sind sehr gut und führen zum Ziel.
Um eine bestehende Website zu 'ajaxifizieren' muss man etwa 20 Zeilen Konfiguration per Copy & Paste in seine web.config einfügen. Das ist auch noch gut erklärt.
Wer aber jetzt denkt, dass seine Website komplett in Ajax ist, hat sich getäuscht (Gott sei Dank). Man kann nun bei den jeweiligen Seiten festlegen welche Formulare und welche Bereiche per Ajax angesteuert werden sollen. Man schreibt einfach in den Html-Text und der Innere Teil lässt sich nun 100% per Ajax steuern. Nahezu uabhängig vom Inhalt. Ziemlich simpel.
Es läuft bei mir auf allen installierten Browsern (IE 6, IE 7, Firefox, Opera) stabil und hat keinerlei Aussetzer.
Nur ein kurzes Beispiel:
Jeder kennt Google Suggest...
Man hat irgendwo ein Textfeld:
Um da nun ein Google-Suggestfähiges Dropdownfeld hinzuzufügen, braucht man nur folgende Zeilen:

<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="cc1" %>
TargetControlID="Recipient" ServicePath="playernames.asmx"
ServiceMethod="GetPlayernames" MinimumPrefixLength="2"
CompletionInterval="1000" EnableCaching="true"
CompletionSetCount="12" />
Die Datei playernames.asmx sieht folgendermaßen aus:

[WebMethod()]
public string[] GetPlayernames(string prefixText, int count)
{
return new String [] { "Name 1", "Name 2", "Name 3" };
}
Im Endeffekt erhält man folgendes Ergebnis:
ajax.asp.net/ajaxtoolkit/AutoComplete/AutoComplete.aspx
Um zu sehen wie schnell man eine ordentliche Applikation programmiert hat, empfehle ich folgendes Video:
download.microsoft.com/download/0/f/6/0f651a0f-6f2b-4497-b061-e1b2825e22e0/MSAJAX-ToDoList.wmv
Nette Nebensache: Sämtlicher Quellcode, der Atlas.Net betrifft, ist freigegeben (teilweise Readonly, teilweise GPL-Like (MS-Shared Source))