Also ich muss bzw. möchte ein großes Projekt programmieren und will dazu AJAX benutzen.
Ich hab dazu mal eine Frage bzw. bräuchte ich ein Lösungsansatz bzw. Tipps für folgendes:
* Der Client schickt die Http request Anfragen
* Der Server verarbeitet Daten und schickt XML zurück (zusammen mit Parameter fürs XSL, um zu wissen welches Template im XSL ich benutzen will)
* Auf dem Client liegt also ein XSL file der beschreibt wie die XML daten dargestellt werden
* Javascript hat einen Prozessor der das XSL mit XML verbindet
Es geht mir einfach darum das ich XSL benutzen will damit ich mir keine großen Gedanken mehr machen muss mit Javascript meine empfangen XML daten an die richtige Stelle in meinem XHTML dokument zu setzten sondern das ich Xml zurückschicke mit einem Paramater der angibt welches Template im XSL file benutzt wird. So wird das ganze Ajax system extrem übersichtlich. Man kann schnell den/die Xsl file/s umtauschen oder bearbeiten um das aussehen zu verändern und man verlagert benötigte Rechenarbeit auf den Clienten.
Ist dies so machbar?
Macht das so Sinn?
Wenn ja wann wird der Xsl File(bzw. Baum) auf den Clienten geladen. Wie merge ich das ganze mit dem XML wenn der File schon auf dem Clienten liegt?
Machen mehrere XSL Files(mit speziellen Templates) mehr Sinn als ein großer mit allen Templates?
Macht es Sinn wenn ich den XSL file(bzw. Baum) immer vor dem XML File (bzw. Baum) zum Clienten schicke. Wie Siehts dann mit Race Conditions aus (also woher weiß ich das der Xsl file eher da ist als der Xml file).
Also ich weiß wie XSL funktioniert, ich weiß wie xml funktioniert, ich weiß wie ajax funktioniert. Ich möchte alles zusammen benutzen und von allen die größten Vorteile gebrauchen. Jemand ne IDEE? Beispiele? Tutorials? Tipps?
Vollständige Version anzeigen: Ajax + XSL Frage?
"Javascript hat einen Prozessor der das XSL mit XML verbindet" hat javascript sowas?
"und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen
was ist mit suchmaschienen und portablen browser / clienthardware?
"und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen
was ist mit suchmaschienen und portablen browser / clienthardware?
Studier Informatik und höre dir die Vorlesungen Web- und Multimediaengineering, Internet Web Applications und als Bonus vielleicht noch Bürokommunikation an, dort werden all deine Fragen beantwortet.
Wenn du mit XSL, XSL-T meinst, das hat per se weder etwas mit JavaScript noch mit Ajax zu tun.
C'ya,
Christian
Wenn du mit XSL, XSL-T meinst, das hat per se weder etwas mit JavaScript noch mit Ajax zu tun.
C'ya,
Christian
1.) Es gibt in Modernen Browsern eine API zu einem XSLT Processor die über JS angesprochen werden kann.
2.) "und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen --> mir aber. Wenn viele concurrent user sich XML Daten processen lassen, so kann es für alle deutlich langsamer werden (durch hohen load), als wenn alle clients selbst processen.
2.) "und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen --> mir aber. Wenn viele concurrent user sich XML Daten processen lassen, so kann es für alle deutlich langsamer werden (durch hohen load), als wenn alle clients selbst processen.
Zitat(EnjoyTheChris @ 14 May 2007, 20:08)
Studier Informatik und höre dir die Vorlesungen Web- und Multimediaengineering, Internet Web Applications und als Bonus vielleicht noch Bürokommunikation an, dort werden all deine Fragen beantwortet.
Wenn du mit XSL, XSL-T meinst, das hat per se weder etwas mit JavaScript noch mit Ajax zu tun.
C'ya,
Christian
Wenn du mit XSL, XSL-T meinst, das hat per se weder etwas mit JavaScript noch mit Ajax zu tun.
C'ya,
Christian
Danke Chris für deine glorreiche Antwort. Ich hab geschrieben das ich Ahnung von Xml, Xsl und Ajax habe. Ich brauch demzufolge deine unfähigen Kommentare nicht. Ich weiß auch das das ganze System wie ich es beschrieben habe funktioniert und auch heutzutage Anwendung findet. Ich wollte konkrete Beispiele und Leute die ein bisschen tiefer in der Materie drin sind als du und mir einfach Anregungen geben können wie es am besten zu lösen sei.
Zitat(aktsizr @ 14 May 2007, 20:19)
1.) Es gibt in Modernen Browsern eine API zu einem XSLT Processor die über JS angesprochen werden kann.
2.) "und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen --> mir aber. Wenn viele concurrent user sich XML Daten processen lassen, so kann es für alle deutlich langsamer werden (durch hohen load), als wenn alle clients selbst processen.
2.) "und man verlagert benötigte Rechenarbeit auf den Clienten" würde mir nicht gefallen --> mir aber. Wenn viele concurrent user sich XML Daten processen lassen, so kann es für alle deutlich langsamer werden (durch hohen load), als wenn alle clients selbst processen.
Richtig! Das ist ein großer Vorteil von Ajax und Hot Creation auf Client-Seite. Mehr Rechenarbeit auf die Clienten zu bringen hat den Vorteil das große Projekte die hohe Anfragen am Tag haben, die Server nicht überlasten. Was zum Beispiel bei Studivz vor einiger Zeit noch ein großes Problem war. Und heutzutage sind fast alle Rechner (auf Client Seite) im Stande solch eine Rechenleistung zu erbringen.
So hat also irgendeiner schon mal mit Xsl und Ajax gearbeitet. Mit Sarissa vielleicht auch?
Der melde sich einfach.
scheinbar niemand...
@aktsizr
Es ist immer eine Frage was man braucht und was man erreichen möchte. Der Verlagerung der Rechenzeit auf den Client steht ja entgegen, dass die Menge der Clients die XSLT-Transformationen kann wesentlich kleiner ist als diejenige die (X)HTML können. Kann man die Anzahl der Benutzer abschätzen, so kann ich auch den Rechenaufwand abschätzen/testen. Habe ich später einmal mehr Benutzer, so kann ich immer noch den Server aufrüsten.
Hat man sich aber einmal für die Clientverarbeitung entschieden, ist auch die Zielgruppe beschränkt und nicht mehr erweiterbar. Brauche ich also später beispielsweise mal doch eine Version für PDAs & Co. muss man doch wieder serverseitige XSLT-Transformationen verwenden. Will man XSL-FO einsetzen (also effektiv PDF-Export), stellt sich die Frage erst gar nicht, da diese kein Browser unterstützt.
Ich bezweifle übrigens, dass die JavaScript-API zum Ansprechen der XSLT-Prozessoren einheitlich ist für IE, Firefox und Opera, lasse mich aber dort gerne eines besseren belehren.
@Timmey
Der Vergleich mit StudiVZ hinkt ja wohl ein bisschen, denn dort kommt weder XML noch XSLT zum Einsatz (zumindestens nicht clientseitig :P ) und bei einer so starken Frequentierung wie dort, wirst du dir auch bei clientseitiger XSLT-Verarbeitung Gedanken machen müssen über Optimierungen zur Serverlast.
C'ya,
Christian
Es ist immer eine Frage was man braucht und was man erreichen möchte. Der Verlagerung der Rechenzeit auf den Client steht ja entgegen, dass die Menge der Clients die XSLT-Transformationen kann wesentlich kleiner ist als diejenige die (X)HTML können. Kann man die Anzahl der Benutzer abschätzen, so kann ich auch den Rechenaufwand abschätzen/testen. Habe ich später einmal mehr Benutzer, so kann ich immer noch den Server aufrüsten.
Hat man sich aber einmal für die Clientverarbeitung entschieden, ist auch die Zielgruppe beschränkt und nicht mehr erweiterbar. Brauche ich also später beispielsweise mal doch eine Version für PDAs & Co. muss man doch wieder serverseitige XSLT-Transformationen verwenden. Will man XSL-FO einsetzen (also effektiv PDF-Export), stellt sich die Frage erst gar nicht, da diese kein Browser unterstützt.
Ich bezweifle übrigens, dass die JavaScript-API zum Ansprechen der XSLT-Prozessoren einheitlich ist für IE, Firefox und Opera, lasse mich aber dort gerne eines besseren belehren.
@Timmey
Der Vergleich mit StudiVZ hinkt ja wohl ein bisschen, denn dort kommt weder XML noch XSLT zum Einsatz (zumindestens nicht clientseitig :P ) und bei einer so starken Frequentierung wie dort, wirst du dir auch bei clientseitiger XSLT-Verarbeitung Gedanken machen müssen über Optimierungen zur Serverlast.
C'ya,
Christian
Ah jo habs gefunden!
http://ajaxpatterns.org/Browser-Side_XSLT
Da wird auch die Frage wo der Xsl Baum herkommt beantwortet!
http://ajaxpatterns.org/Browser-Side_XSLT
Da wird auch die Frage wo der Xsl Baum herkommt beantwortet!
Zitat(EnjoyTheChris @ 15 May 2007, 01:58)
@aktsizr
Es ist immer eine Frage was man braucht und was man erreichen möchte. Der Verlagerung der Rechenzeit auf den Client steht ja entgegen, dass die Menge der Clients die XSLT-Transformationen kann wesentlich kleiner ist als diejenige die (X)HTML können. Kann man die Anzahl der Benutzer abschätzen, so kann ich auch den Rechenaufwand abschätzen/testen. Habe ich später einmal mehr Benutzer, so kann ich immer noch den Server aufrüsten.
Hat man sich aber einmal für die Clientverarbeitung entschieden, ist auch die Zielgruppe beschränkt und nicht mehr erweiterbar. Brauche ich also später beispielsweise mal doch eine Version für PDAs & Co. muss man doch wieder serverseitige XSLT-Transformationen verwenden. Will man XSL-FO einsetzen (also effektiv PDF-Export), stellt sich die Frage erst gar nicht, da diese kein Browser unterstützt.
Ich bezweifle übrigens, dass die JavaScript-API zum Ansprechen der XSLT-Prozessoren einheitlich ist für IE, Firefox und Opera, lasse mich aber dort gerne eines besseren belehren.
Es ist immer eine Frage was man braucht und was man erreichen möchte. Der Verlagerung der Rechenzeit auf den Client steht ja entgegen, dass die Menge der Clients die XSLT-Transformationen kann wesentlich kleiner ist als diejenige die (X)HTML können. Kann man die Anzahl der Benutzer abschätzen, so kann ich auch den Rechenaufwand abschätzen/testen. Habe ich später einmal mehr Benutzer, so kann ich immer noch den Server aufrüsten.
Hat man sich aber einmal für die Clientverarbeitung entschieden, ist auch die Zielgruppe beschränkt und nicht mehr erweiterbar. Brauche ich also später beispielsweise mal doch eine Version für PDAs & Co. muss man doch wieder serverseitige XSLT-Transformationen verwenden. Will man XSL-FO einsetzen (also effektiv PDF-Export), stellt sich die Frage erst gar nicht, da diese kein Browser unterstützt.
Ich bezweifle übrigens, dass die JavaScript-API zum Ansprechen der XSLT-Prozessoren einheitlich ist für IE, Firefox und Opera, lasse mich aber dort gerne eines besseren belehren.
Hallo Chris. www.youtube.com. Mit der Computermouse einen Rechtsklick machen. View source.
Zugegebenermassen nimmt youtube.com auch noch keinen Clientseitegen XSLT Processor sondern lässt sich ein etwas `kurioses' Dokument (z.B.: http://youtube.com//watch_ajax?v=X2BEhk1fq..._comments=1&p=8 ) mittels HTTPXMLRequest() bzw. ActiveX-Pendant ausspucken und innerHTMLt den Inhalt dann an Ort & Stelle. Dennoch lässt sich mit eben damit (obigem `XML' Dokument) auch gut nachvollziehen, warum Client XSLT cool ist: Du sparst nicht nur Rechenzeit sondern hast auch _viel_ geringere Datenredundanz (i.e. keine Formatierungen, die ja per definition schlechtes XML bedeuten). Ganz davon abgesehen, kann man immer vorher abfragen welche, Fähigkeiten der Browser hat...
p.s.: Dennoch: Du bist nen bissl wie 1.0...
p.s.: Dennoch: Du bist nen bissl wie 1.0...
Ich gebe nur die Argumente wieder, die wir in einer der letzten Übung zur VL Internet Web Applications hatten und ich halte sie auch für überzeugend.
Ansonsten sage ich doch gar nicht, dass das eine besser oder das andere schlechter ist. Es kommt auf die Anwendung und Zielgruppe an. Auf Teufel komm raus, alles zu verwenden was hip ist oder hip klingt oder technisch total interessant ist, ist meiner Meinung nach zwar lustig, aber eben auf längere Sicht sicherlich nicht erfolgreich.
C'ya,
Christian
Ansonsten sage ich doch gar nicht, dass das eine besser oder das andere schlechter ist. Es kommt auf die Anwendung und Zielgruppe an. Auf Teufel komm raus, alles zu verwenden was hip ist oder hip klingt oder technisch total interessant ist, ist meiner Meinung nach zwar lustig, aber eben auf längere Sicht sicherlich nicht erfolgreich.
C'ya,
Christian
Gewiss. Aber daher bist du Programmierer/Mediengestalter, nämlich solche Dinge so hinzubekommen, dass sie überall ihre Grundfunktionalität haben und dort, wo es möglich ist auch erweiterte Funktionen besitzen. Beispielsweise wäre es schon ziemlich ärgerlich, wenn beim Umclicken der Kommentare zu den Videos ständig die gesamte Seite (also auch das laufende Video) neu laden würde. Ich weiss auch noch wie es ist wenn man 1000 SLOC Javascript irgendwie auf Opera, NN4/6 & IE4+ zum funktionieren bringen muss, aber die Lehren von gestern sind eben nicht die von heute. Gestern noch war DOM nichts als eine nette Idee. Heute funktioniert das (verhältnissmässig) gut. Man darf bei all der guten Praxis, den neusten, proprietärsten, Kitsch zu vermeiden nicht vergessen, dass etwas von eben dem sich durchsetzt. Und XML/XMLRPC (w/ client & server) sowie XSLT klingt nicht nach Kitsch.
Das habe ich doch auch nicht gesagt. Für dein Kommentarbeispiel braucht man auch kein clientseitiges XSLT, da reicht AJAX und das auch gut so.
Ich habe lediglich einige Nachteile von clientseitigem XSLT genannt, deswegen bin ich doch nicht gegen AJAX & Co. Im Gegenteil, ich finde die Möglichkeiten gerade mit XSLT sehr mächtig. Genau diese Diskussion, ob man XSLT auf dem Client oder Server ausführen sollte, wurde wie schon erwähnt in einer der letzten Übungen zu Internet and Web Applications geführt und diese VL gibt es erst seit diesem Semester.
Und damit ist für mich diese Diskussion beendet, es gibt keine definitive Antwort und ich habe auch nie behauptet eine zu vertreten.
C'ya,
Christian
Ich habe lediglich einige Nachteile von clientseitigem XSLT genannt, deswegen bin ich doch nicht gegen AJAX & Co. Im Gegenteil, ich finde die Möglichkeiten gerade mit XSLT sehr mächtig. Genau diese Diskussion, ob man XSLT auf dem Client oder Server ausführen sollte, wurde wie schon erwähnt in einer der letzten Übungen zu Internet and Web Applications geführt und diese VL gibt es erst seit diesem Semester.
Und damit ist für mich diese Diskussion beendet, es gibt keine definitive Antwort und ich habe auch nie behauptet eine zu vertreten.
C'ya,
Christian
Nein Chris du hast dumm gelabert und das auch noch mit wenig Ahnung! Kein Plan aber erstmal einmischen, das ist der Chris. Viel laber wenig machen, viel Theorie wenig Praxis. Ich denke du hast selbst noch nix mit Xml Xsl (Filetype) oder Ajax programmiert, also halte dich in Zukunft aus solchen Diskussionen raus.