Rich Internet Applications

Rich Internet Applications

Posts 11-15 of 15
  • Torsten Walter
    Torsten Walter    Premium Member
    The company name is only visible to registered members.
    Re^5: Ich mag keine Frameworks...
    Hans Thomas Vogler wrote:
    Torsten Walter schrieb:
    AJS.DIV({id: "mydiv", className: "myClass", style: "backgroundImage:url(/path/to/image.gif")}, "hello world");
     
    Was spricht z.B. dagegen vorher sowas z.B. selber zu schreiben:
    function D0() {
    var foo = document.createElement('div')
    [...]     Weil ich nicht jedesmal das Rad neu erfinden will?! Ansonsten prinzipiell nichts.
    Wenn ich an 10 Projekten gleichzeitig arbeite ist mir auch wichtig überall eine einheitliche Linie zu haben.
    Sollte ich dann das Projekt erweitern müssen oder etwas modifizieren, muss ich nicht nen ganzen Rattenschwanz von Funktionen neu schreiben weil die alten ja zu speziell waren.

    Für DOM-unkundige Aushilfsprogrammierer kann man ja was dazwischenschalten, und nichts anderes tun diese Frameworks letztenendes.
    Klar nachvollziehbarer und weltweit standardisierter Code ist für mich zudem ein Qualitätsmerkmal - und sollte es auch für Kunden sein. Nicht oder nur schwer nachvollziehbarer Code kann für den nämlich tierisch teuer werden. DOM ist standardisiert, weltweit und auch in zehn Jahren noch auf allen Plattformen gültig, anerkannt und implementiert. Verbesserung, Anpassung und Weiterentwicklung ist also auf lange Zeit sichergestellt.     Eben, genau deswegen bevorzuge ich AJS, weil es das eigentliche DOM (was den Code sehr unübersichtlich macht) hinter einer klar strukturierten und lesbaren API kapselt. AJS selbst ist sehr sauber geschrieben und auch leicht erweiterbar, bzw. anpassbar.
     
    Des weiteren gerate ich auf diese Weise garantiert nie in Konflikt mit Urheberrechten und Lizenzbestimmungen, kann ggf. außerdem eigene geltend machen, was im kommerziellen Einsatz unerläßlich ist.     Darüber informiert man sich eben vorher und entscheidet dann ob die Bestimmungen zu dem passen was man vor hat.
     
    Das alles gilt weder für AJS, JABBERWOCK noch für WASWEISSICH.     Da bin ich anderer Meinung...
     
    Vorteil außerdem: ich hole oder baue mir nur genau die Tools und Konstruktoren, die ich wirklich brauche. Das bringt nicht nur Transparenz, sondern eben auch Performance.     Dafür hat zum Beispiel AJS ein Tool, dass genau den Code des Frameworks entfernt der nicht genutzt wird ;)
    Es sei denn... Naja - Konfektionsware war halt immer schon etwas billiger... Stimmt wohl, aber so bleibt auch mehr Zeit für das wesentliche, nämlich dem Kunden die bestmögliche Funktionalität zu erstellen.
    • 26 Mar 2008, 12:52 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Re^2: Die Sache mit dem "innerHTML"
    Torsten Walter schrieb:

    Ich bin nach einigen Versuchen bei AJS hängen geblieben. Das "innerHTML" kommt darin zwar vor, allerdings nur in Hilfsfunktionen um z.B. text in DOM umzuwandeln.
    Das nenne ich ziemlich unelegant... Kollisionen sind so vorprogrammiert und das Framework ist nicht portierbar auf andere Plattformen, wie es eigentlich sein sollte. "innerHTML" ist ein typisches Microsoft-Torf-Gebinde, das Mozilla nachgeknetet hat (ist intern nicht dasselbe und funktioniert übrigens auch völlig anders!), weil es als "Q&D"-Tool (Quick and Dirty) trotzdem praktisch ist zur Konstrukt- und Fehlerkontrolle zwischendurch (Dafür benutz' ich's zugegebenermaßen auch: function zeigMal(foo){alert(document.getElementById(foo).innerHTML)}).

    In einem zur Weitergabe gedachten Software-Tool hat sowas aber eigentlich absolut nichts verloren. Also auch und erst recht in keinem Framework.

    Ansonsten ist alles soweit ich das überblicken kann Standardkonform und arbeitet mit den W3C Specs.
    Muß es ja wohl auch. "innerHTML" ist ja auch der einzige MS-Torfbatzen, den andere (nur Browserhersteller!) übernommen (aber keineswegs gleichartig implementiert!) haben.

    Letzendlich liegts auch an der Implementation. wenn ich einen DIV mit Content erzeuge erstellt AJS einen TextNode. Wenn ich vom Server einen HTML String bekomme muss ich den natürlich erstmal in eien DOM Tree umwandeln, wozu hier innerHTML als Mittel zum Zweck benutzt wird.
    Was ist denn das für ein Server? AJaX bedeutet doch wohl "Asynchroneous Javascript and XML" und nicht "Asynchroneous String Converter". Wenn hierzu "innerHTML" benutzt wird, ist es eben unsauber, weil es an einem DOM-konformen Stringkonverter mangelt. Ist für mich ein Zeichen von Bequemlichkeit. Mangelndes Können mag ich diesbezüglich niemandem unterstellen.

    Viele AJaX-Applikationen benutzen denn auch gar nicht die elementare XML-Komponente, sondern benutzen die Technik, um bloße Textinhalte nachzuladen. Für mich ist das vergleichbar mit jemandem, der einen Porsche benutzt, um auf die andere Straßenseite zu kommen. Hier wie da bezweifle ich, daß damit was gewonnen wäre.

    Aber mit dem Parsen - ob hin oder her - haben's die Framework-Bastler wohl nicht so...

    HTML vom Server zu lesen ist ja auch kein AJAX sondern einfach nur ein HTTP Request.
    Es ist ein Request. Ob's ein XMLHttpRequest ist, steht nochmal auf einem anderen Blatt.

    XSLT ist mir bis jetzt in Frameworks noch nicht über den Weg gelaufen. Aber, ohne hier wie ein Evangelist wirken zu wollen, in AJS kann man das mit den DOM Methoden sehr leicht erstellen/erweitern.
    Klar. Ist ja selbst nur ein XML-Dialekt. Brauch' ich aber auch kein Framework dazu. Ist erschreckend simpel, wenn man's erst begriffen hat. Ein Framework - egal welches - verschleiert für mich nur die Transparenz und schlichte Eleganz.

    Interessant wird AJaX meiner Ansicht nach aber erst richtig, wenn man XML/XSLT zum Vorglühen des Browsers verwendet - als halbdynamische Fallback-Variante sozusagen.

    Auf jeden Fall empfehle ich auf lange Sicht niemandem, zuviel Zeit und Aufmerksamkeit mit Frameworks zu vergeuden, sondern sich besser "in medias res" aufzumachen. Das ist für den Anfang vielleicht etwas mühsamer, macht sich aber auf Dauer bezahlt. Am Ende winkt "Durchblick".

    nix für ungut
    HTV
    • 26 Mar 2008, 8:39 pm
  • Torsten Walter
    Torsten Walter    Premium Member
    The company name is only visible to registered members.
    Re^3: Die Sache mit dem "innerHTML"
    Hans Thomas Vogler wrote:
    Torsten Walter schrieb:
     
    Das nenne ich ziemlich unelegant... Kollisionen sind so vorprogrammiert und das Framework ist nicht portierbar auf andere Plattformen, wie es eigentlich sein sollte. "innerHTML" ist ein typisches Microsoft-Torf-Gebinde, das Mozilla nachgeknetet hat (ist intern nicht dasselbe und funktioniert übrigens auch völlig anders!), [...]     Nicht nur Mozilla, sondern auch Webkit und Opera unterstützen innerHTML. Und soweit mir bekannt ist, ist es die einzige in allen Browsern implementierte Methode einen String in ein DOM Objekt zu parsen ohne einen eigenen Parser zu bauen.
    Bei nochmaligem nachsehen kann ich auch sagen dass innerHTML lediglich als (Q&D) Methode verwendet wird um einen String in DOM umzuwandeln. Wozu ich sagen muss, dass ich die Funktion auch genausogut löschen könnte da ich sie noch nie gebraucht habe...
    [...]
    Muß es ja wohl auch. "innerHTML" ist ja auch der einzige MS-Torfbatzen, den andere (nur Browserhersteller!) übernommen (aber keineswegs gleichartig implementiert!) haben.
    [...]     Die Implementierung ist wohl anders, das Ergebnis ist allerdings das selbe, nämlich ein geparster HTML String.

    [...]
    Was ist denn das für ein Server? AJaX bedeutet doch wohl "Asynchroneous Javascript and XML" und nicht "Asynchroneous String Converter". Wenn hierzu "innerHTML" benutzt wird, ist es eben unsauber, weil es an einem DOM-konformen Stringkonverter mangelt. Ist für mich ein Zeichen von Bequemlichkeit. Mangelndes Können mag ich diesbezüglich niemandem unterstellen.
    [...]     Mir ist wohl bewusst was AJaX bedeutet. Dennoch wird eben vom Server das geliefert was man entsprechend implementiert, also XML, HTML, XHTML oder ASCII Text oder was auch immer. Dem Nutzer, bzw. dem Script ist dann überlassen das Ergebnis richtig zu verarbeiten.
    Viele AJaX-Applikationen benutzen denn auch gar nicht die elementare XML-Komponente, sondern benutzen die Technik, um bloße Textinhalte nachzuladen. Für mich ist das vergleichbar mit jemandem, der einen Porsche benutzt, um auf die andere Straßenseite zu kommen. Hier wie da bezweifle ich, daß damit was gewonnen wäre. Die Natur von XML ist leider massig unnötiger Overhead, weswegen ich ehrlich gesagt auch drumherum navigiere soweit möglich. JSON oder XML zu parsen ist gottseidank browserübergreifend implementiert und soweit ich das überblicke in den meisten Frameworks auch W3C konform implementiert.
    [...]
    Aber mit dem Parsen - ob hin oder her - haben's die Framework-Bastler wohl nicht so...
     
    HTML vom Server zu lesen ist ja auch kein AJAX sondern einfach nur ein HTTP Request.
     
    Es ist ein Request. Ob's ein XMLHttpRequest ist, steht nochmal auf einem anderen Blatt.     Wie gesagt, "richtiges" AJaX wäre es ja nur wenn XML im Spiel wäre, was ich damit vermitteln wollte :)
    [...]
    Klar. Ist ja selbst nur ein XML-Dialekt. Brauch' ich aber auch kein Framework dazu. Ist erschreckend simpel, wenn man's erst begriffen hat. Ein Framework - egal welches - verschleiert für mich nur die Transparenz und schlichte Eleganz.     Da muss ich mich wohl zurückhalten da ich mit XSLT bis jetzt nur einmal kurz in Konakt gekommen bin. Einfach is es wirklich. Aber das HTML zur Darstellung muss ja auch erstmal erstellt werden, ob das nun in selbstgebastelten Methoden geschieht oder ob auf bestehendes zurückgegriffen wird hängt vom individuellen Bedarf ab.
    Interessant wird AJaX meiner Ansicht nach aber erst richtig, wenn man XML/XSLT zum Vorglühen des Browsers verwendet - als halbdynamische Fallback-Variante sozusagen. Das würde ich jetzt gern genauer wissen. Fallback für welchen Fall?

    Auf jeden Fall empfehle ich auf lange Sicht niemandem, zuviel Zeit und Aufmerksamkeit mit Frameworks zu vergeuden, sondern sich besser "in medias res" aufzumachen. Das ist für den Anfang vielleicht etwas mühsamer, macht sich aber auf Dauer bezahlt. Am Ende winkt "Durchblick". Deswegen benutze ich auch Scriptaculous nicht mehr, weil es einfach zu aufgeblasen und unübersichtlich war.
    Wie gesagt, ich bin mit AJS sehr zufrieden weil es sehr klein und flexibel ist. Ich habe es mittlerweile um einiges erweitert und angepasst, so dass es dem was ich ohnehin hätte coden müssen weitestgehend entspricht.

    Da ich allerdings selbst gerade ein Framework baue welches auf AJS aufbaut bin ich wohl auch gerade ein verfechter der Framework Philosophie. Und durch AJS habe ich mir wohl gut einige Monate an arbeit erspart...

    Grüsse aus Osnabrück,
    Torsten

    Übrigens, ich finde die Diskussion sehr interessant. Es ist immer gut andere Standpunkte zu hören. Und bis jetzt bleibt ja alles noch recht friedlich ;)
    • 26 Mar 2008, 9:38 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Re^4: Die Sache mit dem "innerHTML"
    Torsten Walter schrieb:

    Nicht nur Mozilla, sondern auch Webkit und Opera unterstützen innerHTML. Und soweit mir bekannt ist, ist es die einzige in allen Browsern implementierte Methode einen String in ein DOM Objekt zu parsen ohne einen eigenen Parser zu bauen.
    Das ist ja auch nicht unbedingt Aufgabe eines Browsers. Es widerspricht zudem der Kernphilosophie, zwischen CDATA und PCDATA zu unterscheiden.

    Die Implementierung ist wohl anders, das Ergebnis ist allerdings das selbe, nämlich ein geparster HTML String.
    Nein. Es ist vielmehr ein Knotenset, das fehlerhaft sein kann.

    Mir ist wohl bewusst was AJaX bedeutet. Dennoch wird eben vom Server das geliefert was man entsprechend implementiert, also XML, HTML, XHTML oder ASCII Text oder was auch immer. Dem Nutzer, bzw. dem Script ist dann überlassen das Ergebnis richtig zu verarbeiten.
    XMLHttpRequest liefert CDATA *und* PCDATA, damit man sich's nach Bedarf aussuchen kann.

    Die Natur von XML ist leider massig unnötiger Overhead, weswegen ich ehrlich gesagt auch drumherum navigiere soweit möglich. JSON oder XML zu parsen ist gottseidank browserübergreifend implementiert und soweit ich das überblicke in den meisten Frameworks auch W3C konform implementiert.
    "Massig Overhead" sehe ich vielmehr in den Frameworks realisiert. XML ist soooo schön einfach. Das weiß bloß keiner, weil sich alle davor drücken. Und die XML-Nerds haben im Gegenzug oft kaum einen Schimmer von HTML.

    Ist schon ein komischer Planet hier...

    Da muss ich mich wohl zurückhalten da ich mit XSLT bis jetzt nur einmal kurz in Konakt gekommen bin. Einfach is es wirklich. Aber das HTML zur Darstellung muss ja auch erstmal erstellt werden, ob das nun in selbstgebastelten Methoden geschieht oder ob auf bestehendes zurückgegriffen wird hängt vom individuellen Bedarf ab.
    Was ist wohl der Unterschied zwischen weltweit genormten Standards und "selbstgebastelten Methoden"?

    Interessant wird AJaX meiner Ansicht nach aber erst richtig, wenn man XML/XSLT zum Vorglühen des Browsers verwendet - als halbdynamische Fallback-Variante sozusagen.
    Das würde ich jetzt gern genauer wissen. Fallback für welchen Fall?
    Nunja. Bekanntlich kann man nicht unbedingt voraussetzen, daß Javascript aktiv ist. XSLT-Prozessoren erzeugen dynamisch statisches HTML aus beliebiger XML-Quelle. Und es gibt nicht simpleres als einen eigenen, auf den jeweiligen Bedarf zugeschnittenen XML-Dialekt. Das zur Ausgabe nötige Content-Management erledigen die XSL-Templates.

    Auf die Browser wirkt sich beschleunigend aus, daß die Templates gecacht werden, im Idealfall also pro Request nur ein Minimum an Daten tatsächlich übertragen werden muß.

    Das schöne an AJaX ist dann, daß man direkt und unter Umgehung des XSLT-Prozessors auf dieselben Quellen zugreifen kann. Das verschlankt den Datenverkehr noch weiter auf das absolute Minimum. Die Datenbestände, mit denen das DOM-Management dann umgehen muß, sind also leichter zu handhaben als alles andere.

    Was man dann individuell damit zaubern kann, kann sich ein Framework-Hersteller gar nicht alles vorstellen. Framework-Adepten sind und bleiben an dessen Vorstellungen gebunden und können nicht wirklich frei agieren.

    Daß man sie "erweitern" kann, zählt für mich dabei nicht. Was not tut, ist Verschlankung und nicht Erweiterung.

    Da ich allerdings selbst gerade ein Framework baue welches auf AJS aufbaut bin ich wohl auch gerade ein verfechter der Framework Philosophie. Und durch AJS habe ich mir wohl gut einige Monate an arbeit erspart...
    Das eben bezweifle ich. Es gilt nur für den Moment. Auf Dauer bist Du sehr viel schneller, wenn Du Dich völlig frei bewegen kannst und nur Dein aufs Notwendigste reduzierte Werkzeugköfferchen dabei hast.

    Grüsse aus Osnabrück,
    Torsten
    Grüße aus Bad Kohlgrub

    Übrigens, ich finde die Diskussion sehr interessant. Es ist immer gut andere Standpunkte zu hören. Und bis jetzt bleibt ja alles noch recht friedlich ;)
    Ich bin ja auch niemandem böse. Ich will nur kon-frontieren, und das ist ja wohl nichts an sich schlechtes.

    servus,
    HTV
    • 27 Mar 2008, 12:27 am
  • Torsten Walter
    Torsten Walter    Premium Member
    The company name is only visible to registered members.
    Re^5: Die Sache mit dem "innerHTML"
    Diesmal ohne Zitat ;)

    Zum thema XML muss ich mich wohl geschlagen geben. Dort habe ich lediglich beschränkte Erfahrungen.
    XML ist bis jetzt nur zur Verwendung gekommen um Datensätze auch von nicht Programmierern konfigurieren zu können. Da bin ich allerdings mittlerweile auf YAML umgestiegen.

    Im Moment baue ich ein XML interface um die Level-Objektstruktur meines Game Frameworks zu speichern/laden. Wobei XML auch nur eine Alternative zu JSON und YAML sein wird.

    Ich hatte also bisher noch keinen Bedarf XML Daten Grafisch aufzubereiten, zumindest nicht direkt.

    Das XML einfach ist, dem Stimme ich 100%ig zu. Jeder kann sich ja seinen Dialekt entwerfen, was natürlich auch wieder zu anderen Problemen führt. Der Overhead bei XML besteht meiner Meinung nach vor allem am Markup. Das geht bei Alternativen wesentlich kompakter.

    Die "selbstgebastelten Methoden" hast du offensichtlich in den falschen Hals bekommen. Ich meinte natürlich die DOM Methoden in selbstgebaute Methoden zu kapseln (um nicht jedesmal einen Rattenschwanz an setAttribute's zu haben) oder auf ein kompaktes Framework (was weder Prototype noch MooTools ist) zurückzugreifen ist der Situation angemessen zu entscheiden. Bei einigen wenigen calls und speziellen Anforderungen ist ein Framework zuviel des Guten.

    Bei 1000+ Zeilen JS Code, 10.000+ Objekten und massig DOM calls die dynamisch erzeugt werden macht meiner Ansicht nach ein Framework Sinn. Besonders wenn das Framework an sich weniger als 1/3 des gesamten Code Aufkommens ausmacht.

    ---
    XSLT:
    Das kling interessant. Jetzt brauch ich nur noch ein Projekt um das mal auszuprobieren. Ich finde auch nicht dass 10KiB(komplett,minimiert) für ein Framework besonders viel Overhead ist.

    Und dann doch ein Zitat:
    Da ich allerdings selbst gerade ein Framework baue welches auf AJS aufbaut bin ich wohl auch gerade ein
    verfechter der Framework Philosophie. Und durch AJS habe ich mir wohl gut einige Monate an arbeit erspart...
     
    Das eben bezweifle ich. Es gilt nur für den Moment. Auf Dauer bist Du sehr viel schneller, wenn Du Dich völlig
    frei bewegen kannst und nur Dein aufs Notwendigste reduzierte Werkzeugköfferchen dabei hast.
    Eben genau aus dem Grund habe ich nach vielen Versuchen AJS implementiert. Es hat das nötigste, kann bei Bedarf minimiert werden, die Syntax ist sehr angenehm und entspricht meinem eigenen Stil.
    Ich hatte bereits fast die gesamten DOM und Array Funktionen selbst gebaut. Letzendlich bin ich dann doch umgestiegen weil ich erkannte dass ich das Rad eben nicht erfinden muss wenn es schon jemand für mich getan hat.
    Selbst mit einem Framework kann ich mich frei bewegen, es zwingt mich ja niemand das Framework so zu benutzen wie es da steht, ich kann ja alles entsprechend erweitern, kürzen, löschen oder sonstwie nach Bedarf ändern. Wie gesagt, habe ich das auch bereits getan und wohl schon tiefgreifende Spuren hinterlassen.
    This post was modified on 27 Mar 2008 at 11:10 am.
    • 27 Mar 2008, 11:09 am