XMLHttpRequest

[Gerd Gruber]

Hallo Leute,

wie gerade auf
http://www.heise.de/newsticker/meldung/66617
zu erfahren ist, hat SelfHTML einen Versionssprung auf 8.1.1 gemacht.
Respekt an die Verantwortlichen und Danke für Ihre unermüdliche Arbeit.

Jetzt aber doch ein Kritikpunkt:
Da ja AJAX (synchronous Javascript and XML) in letzter Zeit in aller Munde ist, und die Gestaltung, Design und nicht zuletzt die Usability einer Webseite entscheidend beeinflussen kann, verstehe ich nicht ganz wieso dieses Thema auch jetzt beim Update völlig vernachläßigt worden ist.
Ich habe jedenfall nicht zum object.
window.XMLHttpRequest bzw. in MS gesprochen ActiveXObject("Microsoft.XMLHTTP") gefunden.
Eine Suche nach XMLHttpRequest bringt "keine Treffer".
Im Forum hier wurde dieses Objekt schon mehrmals behandelt und auch kompetent beschrieben, aber ich finde, es gehört wegen seiner Wichtigkeit, die dieses Thema in letzter Zeit gefunden hat, schon auch ausführlich in den offiziellen selfHTML-Seiten besprochen.

Deshalb direkt dir Frage an Stefan Münz: Wieso wurden AJAX und insbesondere die Objekte window.XMLHttpRequest bzw. ActiveXObject("Microsoft.XMLHTTP") kein Platz eingeräumt?

Ansonsten viel Lob für die geleistet Arbeit, die eigentlich auch von mir nicht hoch genug eingeschätz werden kann und von der ich auch schon häufig profitiert habe.

viele Grüße

Gerd

[Tim Tepaße]

Hallo,

Da ja AJAX (synchronous Javascript and XML) in letzter Zeit in aller Munde ist, und die Gestaltung, Design und nicht zuletzt die Usability einer Webseite entscheidend beeinflussen kann, verstehe ich nicht ganz wieso dieses Thema auch jetzt beim Update völlig vernachläßigt worden ist.

Weil das Update zum größeren Teil ein Fehlerbeseitigungsrelease ist - deswegen auch der kleine Versionssprung von 8.1 auf 8.1.1. Wir sind uns natürlich dieses Themenkomplexes bewusst und schätzen ihn als recht wichtig ein, insbesondere, da es durch die Popularität von Ajax zu einigen tiefergreifenden Änderungen im Prozedere der Seitengestaltung kommt. Übliche Grundsätze wie „graceful degregation“ gelten teilweise nicht mehr, es tauchen neue Usability-Probleme wie zum Beispiel das Problem des Back-Buttons auf. Diese Themen werden ja auch in den letzten Monaten kontrovers in der – größtenteils englischsprachigen – Blogosphäre diskutiert. Diese Themen halbwegs ausführlich zu dokumentieren ist in einem Fehlerbeseitigungsrelease nicht drin, schon allein wegen größerer struktureller Probleme im Kapitel Javascript/DOM.

Wie Du im SELFHTML Weblog nachlesen kannst, konzentrieren wir uns für die größeren Änderungen auf die zu entwickelnde Version 9 von SELFHTML, dort ist geplant, Ajax und ähnlich aktuelle oder aktuell werdende Themen neu mit aufzunehmen. In etwaigen zukünftigen Versionen 8.1.x wird dies nicht mehr geschehen.

Deshalb direkt dir Frage an Stefan Münz:

Nebenbei: Stefan schreibt wegen Arbeitslast und seines reichhaltigen Familienlebens (mehrere Kinder) nicht mehr alleine an SELFHTML, es gibt inzwischen eine SELFHTML Redaktion. SELFHTML 8.x ist im wesentlichen aber immer noch das Produkt von Stefan.

Wieso wurden AJAX und insbesondere die Objekte window.XMLHttpRequest bzw. ActiveXObject("Microsoft.XMLHTTP") kein Platz eingeräumt?

Wenn es Dir nur um XMLHttpRequest geht, dann gibt es vielleicht in näherer oder etwas entfernter Zukunft Hoffnung für Dich. Ich habe seit einiger Zeit einen Feature Artikel in Vorbereitung, der konkret XMLHttpRequest und diverse Nutzungen desselben behandelt. Ich hoffe darauf, diesen noch vor Weihnachten zu veröffentlichen, das hängt aber auch von sonstiger Arbeitsbelastung. Wenn Du jetzt leicht höhnisches Gelächter im Hintergrund hörst – ich habe hier berechtigterweise das Image eines leichten Hangs zu Terminüberziehungen. Über kurz oder lang kommt da aber was.

Tim

[Thomas J.S.]

Hallo Tim,

Wenn es Dir nur um XMLHttpRequest geht, dann gibt es vielleicht in näherer oder etwas entfernter Zukunft Hoffnung für Dich. Ich habe seit einiger Zeit einen Feature Artikel in Vorbereitung, der konkret XMLHttpRequest und diverse Nutzungen desselben behandelt.

Gut, dass du das erwähnst, vielleicht sollte ich auch mal meine zwei Artikel zu XMLHttprequest und XML/XSLT-Verarbeitung, die ich seit eineinhalb Jahren da liegen habe aktualisieren und beenden *sigh, so viel zu tun und so wenig zeit*

Grüße
THomas

[Marc Reichelt]

Hallo ihr beiden,

Wenn es Dir nur um XMLHttpRequest geht, dann gibt es vielleicht in näherer oder etwas entfernter Zukunft Hoffnung für Dich. Ich habe seit einiger Zeit einen Feature Artikel in Vorbereitung, der konkret XMLHttpRequest und diverse Nutzungen desselben behandelt.

Gut, dass du das erwähnst, vielleicht sollte ich auch mal meine zwei Artikel zu XMLHttprequest und XML/XSLT-Verarbeitung, die ich seit eineinhalb Jahren da liegen habe aktualisieren und beenden *sigh, so viel zu tun und so wenig zeit*

das erinnert mich doch glatt daran, dass ich auch einen Feature-Artikel schreiben wollte - über QEMU. Aber irgendwie bekomme ich das wegen meiner schlechten Zeitplanung momentan nicht hin. :-(
Erst mal muss ich bei der Uni wieder einiges aufholen - dann kann ich mir auch solche "Nebentätigkeiten" wieder erlauben.

Betreffend SELFHTML 9.0: Ist geplant, das Thema Flash in der neuen Version von SELFHTML zu erwähnen? Meiner Meinung muss da erst mal nichts ausführliches, aber doch grundlegendes geleistet werden. Und da es mittlerweile auch OpenSource-Compiler gibt, dürfte das doch auch ok gehen.
Ich fände es toll, wenn ihr darüber mal in eurer nächsten Redaktionskonferenz schwätzen könntet. Mir geht es nicht um Flash als Allheilmittel, sondern um Flash als eine Ergänzung an sinnvollen Stellen - ihr kennt mich ja... ;-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Vinzenz Mai]

Hallo Marc,

das erinnert mich doch glatt daran, dass ich auch einen Feature-Artikel schreiben wollte - über QEMU. Aber irgendwie bekomme ich das wegen meiner schlechten Zeitplanung momentan nicht hin. :-(

das ist schade, denn wir warten, aber ...

Erst mal muss ich bei der Uni wieder einiges aufholen - dann kann ich mir auch solche "Nebentätigkeiten" wieder erlauben.

... Du setzt die Prioritäten schon richtig.

Freundliche Grüße

Vinzenz

[molily]

Hallo,

Ist geplant, das Thema Flash in der neuen Version von SELFHTML zu erwähnen? Meiner Meinung muss da erst mal nichts ausführliches, aber doch grundlegendes geleistet werden.

Flash wird momentan nur sehr verhalten, wenn nicht sogar übertrieben skeptisch angesprochen. Das ist zum einen nicht zeitgemäß, zum anderen fehlt eine nähere Abhandlung von Flash als Ergänzung an sinnvollen Stellen, wie du sagst. Auf jeden Fall soll Flash mehr Raum zugestanden werden.

Und da es mittlerweile auch OpenSource-Compiler gibt, dürfte das doch auch ok gehen.

Naja. Was heißt Compiler? Muss man dann aufwändig irgendeinen Quellcode schreiben? Ich bin nicht sonderlich informiert, aber soweit ich weiß, sind solche Methoden längst nicht so praktikabel wie die Arbeit mit der konstenpflichtigen Authoring-Software von Macromedia.
Diese Umstände sind wohl auch der Grund dafür, warum eine kurze Einführung in Flash nur schwerlich in SELFHTML passen würde. Natürlich sollte vermittelt werden, wozu Flash gebraucht werden kann, welche Möglichkeiten damit zur Verfügung stehen und welche Tools man dazu benötigt. Eine solche Erklärung kann aber letztlich nur ein Verweis bleiben, unterscheidet sich Flash doch grundlegend von allen anderen in SELFHTML bisher angesprochenen Sprachen und Konzepten. Dass den meisten SELFHTML-Lesern eine komfortable Authoring-Software für Flash fehlt, tut sein übriges.

Mathias

[Marc Reichelt]

Hallo molily,

Ist geplant, das Thema Flash in der neuen Version von SELFHTML zu erwähnen? Meiner Meinung muss da erst mal nichts ausführliches, aber doch grundlegendes geleistet werden.

Flash wird momentan nur sehr verhalten, wenn nicht sogar übertrieben skeptisch angesprochen. Das ist zum einen nicht zeitgemäß, zum anderen fehlt eine nähere Abhandlung von Flash als Ergänzung an sinnvollen Stellen, wie du sagst. Auf jeden Fall soll Flash mehr Raum zugestanden werden.

Super, damit ist meine erste Frage schon mal beantwortet. :-)

Und da es mittlerweile auch OpenSource-Compiler gibt, dürfte das doch auch ok gehen.

Naja. Was heißt Compiler? Muss man dann aufwändig irgendeinen Quellcode schreiben? Ich bin nicht sonderlich informiert, aber soweit ich weiß, sind solche Methoden längst nicht so praktikabel wie die Arbeit mit der konstenpflichtigen Authoring-Software von Macromedia.

Um das Prinzip zu erklären:
Macromedia Flash ist ein geschlossenes und kostenpflichtiges Tool, SWF ist mittlerweile ein zwar binärer, aber freier Standard. Deshalb gibt es sogar bereits einige OpenSource-Compiler, die nichts anderes machen, als ActionScript 2.0-Code in Bytecode umzuwandeln (für SWF-Dateien benötigt). Und sie machen das sehr schnell und sogar besser (z.B. mit Warnungen etc.) als der Compiler im offiziellen Macromedia Flash. Hier sei z.B. MTASC erwähnt. Das ist jetzt allerdings nur für ActionScript, d.h. da muss man direkt über den ActionScript-Code die Grafiken erzeugen oder aus bestehenden SWF-Dateien importieren, was auf Dauer etwas lästig ist. Es gibt aber andere Tools (z.B. swfmil), die genau das übernehmen.
Die Verbindung der beiden Tools MTASC und swfmill ist super, um frische SWF-Dateien zu generieren. Und im Gegensatz zum derzeitigen kommerziellen Tool kann man das sogar automatisiert (beispielsweise mit Bash-Skripts) erledigen lassen. Zudem sind die Tools kostenlos und OpenSource.

Diese Umstände sind wohl auch der Grund dafür, warum eine kurze Einführung in Flash nur schwerlich in SELFHTML passen würde. Natürlich sollte vermittelt werden, wozu Flash gebraucht werden kann, welche Möglichkeiten damit zur Verfügung stehen und welche Tools man dazu benötigt. Eine solche Erklärung kann aber letztlich nur ein Verweis bleiben, unterscheidet sich Flash doch grundlegend von allen anderen in SELFHTML bisher angesprochenen Sprachen und Konzepten. Dass den meisten SELFHTML-Lesern eine komfortable Authoring-Software für Flash fehlt, tut sein übriges.

Natürlich sollte es für das Tool von Macromedia eine Seite geben, die allerdings auch auf die OpenSource-Alternativen hinweist. Im Grunde stelle ich mir eine solche Struktur vor:

+------------------+
                 ------| Macromedia Flash |-----
+----------+     |     +------------------+    |     +------------------+
| Einstieg |-----|                             |-----| ActionScript 2.0 |
+----------+     |     +------------------+    |     +------------------+
                 ------| OpenSource-Tools |-----
                       +------------------+

D.h. es gibt erst einen zentralen Einstieg, der auf die Unterschiede zwischen den beiden eigentlichen Einführungen hinweist. Die beiden Einführungen dann zeigen die Grundprinzipien der Tools - und sollen prinzipiell dazu dienen, dem Leser zu zeigen, wo ActionScript ins Spiel kommt, mit einigen grundlegenden Beispielen.

Denn ActionScript macht Flash erst richtig dynamisch, damit kann man viele Dinge erledigen: Sounds (MP3) und Videos (FLV) laden und abspielen, XML-Daten parsen, mit Server kommunizieren, etc.

Der letzte (und wichtigste!) Teil ist dann der mit ActionScript, der ja unabhängig von dem verwendeten Tool geschrieben werden kann. Mit prinzipiellen Beispielen, und zuletzt ein Verweis auf die aktuellste ActionScript-Referenz.

Das Ziel für SELFHTML sollte für mich auf jeden Fall darin bestehen, Dinge mit Flash aufzuzeigen, die mit den heutigen Mitteln einfach nur schlecht realisierbar sind (siehe EMFF). Und natürlich darauf hinweisen, wie es eigentlich sein sollte (EMFF dient ja nur zum Abspielen von MP3s, das könnten die heutigen Browser eigentlich erledigen - sogar ohne Plugins).

Hier natürlich noch ein Link, den ich im Zusammenhang mit Flash gerne setze:
http://www.osflash.org/

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Christian Seiler]

Hallo Marc,

Macromedia Flash ist ein geschlossenes und kostenpflichtiges Tool,

Ja.

SWF ist mittlerweile ein zwar binärer, aber freier Standard.

Nein, definitiv nicht. Ob es ein Standard ist, darüber kann man sich streiten (je nachdem, wie man Standard definiert), aber frei ist das Format definitiv nicht. Aus http://download.macromedia.com/pub/flash/flash_file_format_specification.pdf, Appendix 2 geht nämlich ganz klar hervor:

2. Licenses
   Pursuant to the terms and conditions of this License, you are granted a
   nonexclusive license to use the Specification for the sole purposes of
   developing Products that output SWF.
   [...]
3. Restrictions
   a. You may not use the Specification in any way to create or develop a
   runtime, client, player, executable or other program that reads or renders
   .swf.

Du darfst also Programme schreiben, die SWF-Dateien erstellen, *nicht* jedoch Programme, die SWF-Dateien lesen. Die Lizenz ist somit meiner Ansicht nach sogar GPL-Inkompatibel, da - wenn Du ein GPL-Programm schreiben würdest, das nur Flash-Dateien schreibt - jemand anderes nach der GPL theoretisch das Recht hätte, das Programm so umzuschreiben, das es auch Flash-Dateien liest. Das würde aber widerum dazu führen, dass Du die Lizenz des obigen Dokumentes verletzt hast (indem Du mitgeholfen hast, ein Flash lesendes Programm zu erstellen). Inwieweit die obigen Lizenzbedingungen nach deutschem Recht gültig sind, kann ich nicht beurteilen, in den USA sind sie es jedenfalls - und aus dem Grund gilt: Das Dateiformat ist nicht frei, weil Du damit keine Programme schreiben darfst, die das Format lesen und zumindest meiner Ansicht nach auch keine GPL-Programme schreiben darfst, die das Format schreiben.

D.h. es gibt erst einen zentralen Einstieg, der auf die Unterschiede zwischen den beiden eigentlichen Einführungen hinweist. Die beiden Einführungen dann zeigen die Grundprinzipien der Tools - und sollen prinzipiell dazu dienen, dem Leser zu zeigen, wo ActionScript ins Spiel kommt, mit einigen grundlegenden Beispielen.

Für mich hört sich das nach einer *Menge* Stoff an - v.a. wenn Du ActionScript noch einführen willst (wenn auch nur etwas) - so wie ich Mathias verstanden habe, hatte er eigentlich eher eine Einführung im Stil »Was kann man prinzipiell alles damit machen, was ist sinnvoll, was weniger und wo finde ich Informationen dazu, wenn ich mich da einarbeiten will« im Sinn. Für SELFHTML 9.0 steht noch eine ganze Menge an Themen an, die in SELFHTML nur teilweise oder gar nicht behandelt werden (PHP, Datenbanken, JavaScript-Objektmodell, evtl. SVG, AJAX ...). Deswegen und zumal es deutlich bessere Resourcen zu Flash gibt, als es in SELFHTML je beschrieben werden kann, halte ich eine etwas kürzerere Einführung für sinnvoller.

Viele Grüße,
Christian

[Felix Riesterer]

Lieber Christian,

[...] Für SELFHTML 9.0 steht noch eine ganze Menge an Themen an, die in SELFHTML nur teilweise oder gar nicht behandelt werden (PHP, Datenbanken, JavaScript-Objektmodell, evtl. SVG, AJAX ...).

da wird dann wohl ein regelrechtes SelfWebTechnologies daraus...?

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Christian Seiler]

Hallo Felix,

da wird dann wohl ein regelrechtes SelfWebTechnologies daraus...?

Das wird die Zukunft zeigen, ob wir tatsächlich alles hinkriegen, was wir uns vorgenommen haben. ;-)

Viele Grüße,
Christian

[Marc Reichelt]

Hallo Christian,

SWF ist mittlerweile ein zwar binärer, aber freier Standard.

Nein, definitiv nicht. Ob es ein Standard ist, darüber kann man sich streiten (je nachdem, wie man Standard definiert), aber frei ist das Format definitiv nicht. Aus http://download.macromedia.com/pub/flash/flash_file_format_specification.pdf, Appendix 2 geht nämlich ganz klar hervor:

2. Licenses
   Pursuant to the terms and conditions of this License, you are granted a
   nonexclusive license to use the Specification for the sole purposes of
   developing Products that output SWF.
   [...]
3. Restrictions
   a. You may not use the Specification in any way to create or develop a
   runtime, client, player, executable or other program that reads or renders
   .swf.

Du darfst also Programme schreiben, die SWF-Dateien erstellen, *nicht* jedoch Programme, die SWF-Dateien lesen. Die Lizenz ist somit meiner Ansicht nach sogar GPL-Inkompatibel, da - wenn Du ein GPL-Programm schreiben würdest, das nur Flash-Dateien schreibt - jemand anderes nach der GPL theoretisch das Recht hätte, das Programm so umzuschreiben, das es auch Flash-Dateien liest. Das würde aber widerum dazu führen, dass Du die Lizenz des obigen Dokumentes verletzt hast (indem Du mitgeholfen hast, ein Flash lesendes Programm zu erstellen). Inwieweit die obigen Lizenzbedingungen nach deutschem Recht gültig sind, kann ich nicht beurteilen, in den USA sind sie es jedenfalls - und aus dem Grund gilt: Das Dateiformat ist nicht frei, weil Du damit keine Programme schreiben darfst, die das Format lesen und zumindest meiner Ansicht nach auch keine GPL-Programme schreiben darfst, die das Format schreiben.

Sehr interessantes Dokument das, danke. :-)
Allerdings finde ich, dass man die "Restrictions" durchaus anders auslegen kann.
Dort steht, dass man die Spezifikation (das PDF-Dokument) nicht dazu benutzen darf, um Programme zu schreiben, die SWF-Dateien einlesen.
Daher darf man SWF-Dateien aber trotzdem einlesen (und ausführen etc.), wenn man die Spezifikation nicht benutzt. Für das Schreiben von Programmen, die zwar SWF-Dateien erstellen können, für die die Spezifikation aber ebenfalls nicht benutzt wurde, ist sie also auch irrelevant.
Dazu ist auch der erste Abschnitt ("Definitions") interessant, in der die Spezifikation definiert wird.

Natürlich ist es mit dem Dokument leichter - vielleicht sollte man daher trotzdem mal bei Macromedia [oder vielleicht Adobe] anfragen, ob sie mit der OpenSource-Community zusammenarbeiten möchten. Ansonsten läuft die Community ihnen davon, wie sie es schon in vielen anderen Fällen gemacht hat. Und schließlich bekommt Flash bald eine mächtige Konkurrenz aus dem Hause Microsoft, weswegen eine Zusammenarbeit mit der OpenSource-Community die klügste Entscheidung für Macromedia wäre.

Da kommt mir außerdem eine Idee (wahh, schon der 25. Punkt auf meiner Liste - oder der 30.?): Ein neues Multimedia-Format zu entwickeln, das ähnliche Möglichkeiten hat wie SWF. Und zwar ein offen dokumentiertes - dafür ist es dann sehr einfach möglich, sowohl lesende als auch schreibende Programme zu entwickeln. Das wird über kurz oder lang sogar vielleicht passieren - und es wäre für Macromedia ebenso schlecht wie wenn Microsoft ihnen zuvorkommt.

D.h. es gibt erst einen zentralen Einstieg, der auf die Unterschiede zwischen den beiden eigentlichen Einführungen hinweist. Die beiden Einführungen dann zeigen die Grundprinzipien der Tools - und sollen prinzipiell dazu dienen, dem Leser zu zeigen, wo ActionScript ins Spiel kommt, mit einigen grundlegenden Beispielen.

Für mich hört sich das nach einer *Menge* Stoff an - v.a. wenn Du ActionScript noch einführen willst (wenn auch nur etwas) - so wie ich Mathias verstanden habe, hatte er eigentlich eher eine Einführung im Stil »Was kann man prinzipiell alles damit machen, was ist sinnvoll, was weniger und wo finde ich Informationen dazu, wenn ich mich da einarbeiten will« im Sinn.

Ich weiß, und das ist auch der Grund, warum ich Flash bei SELFHTML gerne einführen würde.
Da SELFHTML mittlerweile eine starke Leserschaft hat, wäre das Internet vielleicht in der Zeit darauf ein Stückchen von sinnlosen Flash Intros und Menüs befreit. Das ist das Ziel, das ich anstrebe - den Leuten zu zeigen, wo Flash Sinn macht, und wo nicht.

Für SELFHTML 9.0 steht noch eine ganze Menge an Themen an, die in SELFHTML nur teilweise oder gar nicht behandelt werden (PHP, Datenbanken, JavaScript-Objektmodell, evtl. SVG, AJAX ...). Deswegen und zumal es deutlich bessere Resourcen zu Flash gibt, als es in SELFHTML je beschrieben werden kann, halte ich eine etwas kürzerere Einführung für sinnvoller.

Deshalb bezeichne ich es ja auch als Einführung. ;-)
SELFHTML 9.0 wird also endlich etwas aktueller. Und natürlich gibt es bei Flash wesentlich bessere Ressourcen als es bei SELFHTML geben wird - aber gibt es das bei PHP nicht auch? Oder Datenbanken? Das wäre für mich also kein Grund, Flash unwichtiger als die anderen von dir erwähnten Themen erscheinen zu lassen. Es ist heute weitaus verbreiteter als SVG, auch, wenn ich dieses gegenüber Flash vorziehe. Aber wir sollten auch einsehen, was SVG nicht kann. Und, dass der immer noch "beliebteste Browser der Welt" (der-der-nicht-genannt-werden-darf) ohne Plugin kein SVG unterstützt.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Christian Seiler]

Hallo Marc,

Allerdings finde ich, dass man die "Restrictions" durchaus anders auslegen kann.
Dort steht, dass man die Spezifikation (das PDF-Dokument) nicht dazu benutzen darf, um Programme zu schreiben, die SWF-Dateien einlesen.
Daher darf man SWF-Dateien aber trotzdem einlesen (und ausführen etc.), wenn man die Spezifikation nicht benutzt. Für das Schreiben von Programmen, die zwar SWF-Dateien erstellen können, für die die Spezifikation aber ebenfalls nicht benutzt wurde, ist sie also auch irrelevant.

Super. Gleiches gilt für das Microsoft-Office-Format: Niemand kann mir verbieten, ein Programm zu schreiben, das das Format liest, solange ich keine MS-internen Dokumente verwende (was ja bei bspw. OOo getan wurde), würdest Du das MS-Office-Format allerdings als offen bezeichnen?

Viele Grüße,
Christian

[Marc Reichelt]

Hallo Christian,

Hallo Marc,

Allerdings finde ich, dass man die "Restrictions" durchaus anders auslegen kann.
Dort steht, dass man die Spezifikation (das PDF-Dokument) nicht dazu benutzen darf, um Programme zu schreiben, die SWF-Dateien einlesen.
Daher darf man SWF-Dateien aber trotzdem einlesen (und ausführen etc.), wenn man die Spezifikation nicht benutzt. Für das Schreiben von Programmen, die zwar SWF-Dateien erstellen können, für die die Spezifikation aber ebenfalls nicht benutzt wurde, ist sie also auch irrelevant.

Super. Gleiches gilt für das Microsoft-Office-Format: Niemand kann mir verbieten, ein Programm zu schreiben, das das Format liest, solange ich keine MS-internen Dokumente verwende (was ja bei bspw. OOo getan wurde), würdest Du das MS-Office-Format allerdings als offen bezeichnen?

Nein, das allerdings nicht. Mit offen habe ich mich in meinem ursprünglichen Posting leider etwas vertan, ich hätte besser das Wort "dokumentiert" verwenden sollen. ;-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[at]

Hallo.

Niemand kann mir verbieten, ein Programm zu schreiben, das das Format liest, solange ich keine MS-internen Dokumente verwende (was ja bei bspw. OOo getan wurde), würdest Du das MS-Office-Format allerdings als offen bezeichnen?

Würdest du OpenOffice etc. deshalb als inkompatibel zur GPL bezeichnen?
MfG, at

[Christian Seiler]

Hallo at,

Niemand kann mir verbieten, ein Programm zu schreiben, das das Format liest, solange ich keine MS-internen Dokumente verwende (was ja bei bspw. OOo getan wurde), würdest Du das MS-Office-Format allerdings als offen bezeichnen?

Würdest du OpenOffice etc. deshalb als inkompatibel zur GPL bezeichnen?

Ich weiß jetzt nicht auswendig, unter welcher Lizenz OOo steht, allerdings dürfte es kein Problem sein, wenn OOo unter der GPL stehen würde (oder es tatsächlich tut). Es ist ja auch nicht verboten, GPL-Programme zu schreiben, die MS Office oder Flash lesen oder schreiben - das habe ich ja nicht gesagt. Mir ging's nur darum: Es ist meiner Ansicht nach nicht möglich mit Hilfe von Informationen, die man aus der offiziellen Flash-Dateiformat-Spezifikation erhalten, GPL-Programme zu schreiben. Wenn man die Informationen sich anderswie beschafft (ausprobieren, auf bereits erstellte Dateien glotzen und hoffen, dass man inspieriert wird, ...), dann ist es kein Problem (solange die Art der Beschaffung rechtens war). Es gibt ja auch einen sich in der Entwicklung befindlichen Flash-Player(!)-Klon, der unter der GPL steht: http://gplflash.sourceforge.net/ Der ist jedoch genauso wie die MS-Office-Importfilter von OOo entstanden und nicht mit Hilfe der Spezifikation.

Viele Grüße,
Christian

[at]

Hallo.

Ich weiß jetzt nicht auswendig, unter welcher Lizenz OOo steht, allerdings dürfte es kein Problem sein, wenn OOo unter der GPL stehen würde (oder es tatsächlich tut). Es ist ja auch nicht verboten, GPL-Programme zu schreiben, die MS Office oder Flash lesen oder schreiben - das habe ich ja nicht gesagt.

Stimmt, du hast dich auf Flash bezogen:

Du darfst also Programme schreiben, die SWF-Dateien erstellen, *nicht* jedoch Programme, die SWF-Dateien lesen. Die Lizenz ist somit meiner Ansicht nach sogar GPL-Inkompatibel, da - wenn Du ein GPL-Programm schreiben würdest, das nur Flash-Dateien schreibt - jemand anderes nach der GPL theoretisch das Recht hätte, das Programm so umzuschreiben, das es auch Flash-Dateien liest.

Mir ging's nur darum: Es ist meiner Ansicht nach nicht möglich mit Hilfe von Informationen, die man aus der offiziellen Flash-Dateiformat-Spezifikation erhalten, GPL-Programme zu schreiben. Wenn man die Informationen sich anderswie beschafft (ausprobieren, auf bereits erstellte Dateien glotzen und hoffen, dass man inspieriert wird, ...), dann ist es kein Problem (solange die Art der Beschaffung rechtens war). Es gibt ja auch einen sich in der Entwicklung befindlichen Flash-Player(!)-Klon, der unter der GPL steht: http://gplflash.sourceforge.net/ Der ist jedoch genauso wie die MS-Office-Importfilter von OOo entstanden und nicht mit Hilfe der Spezifikation.

Mir ging es nur darum: Du hattest etwas ganz anderes und kaum nachvollziehbares geschrieben.
MfG, at

[Christian Kruse]

你好 at,

Mir ging es nur darum: Du hattest etwas ganz anderes und kaum
nachvollziehbares geschrieben.

Also, ich hatte den Text genau so verstanden. :)

再见,
 克里斯蒂安

[at]

Hallo.

Mir ging es nur darum: Du hattest etwas ganz anderes und kaum
nachvollziehbares geschrieben.

Also, ich hatte den Text genau so verstanden. :)

Ich auch. Nachvollziehen kann ich ihn dennoch nicht, weil er -- wie gesagt -- etwas anderes aussagt.
MfG, at

[Felix Riesterer]

Lieber Marc,

SELFHTML 9.0 wird also endlich etwas aktueller. Und natürlich gibt es bei Flash wesentlich bessere Ressourcen als es bei SELFHTML geben wird - aber gibt es das bei PHP nicht auch? Oder Datenbanken?

und damit würde SelfHTML 9 seiner eigenen Tradition treu bleiben, indem es in diese Web-Technologien einführt, die wesentlichen Merkmale, Eigenschaften und Einsatzmöglichkeiten beschreibt und auf weiterführende Resourcen verweist. Je nach Gutdünken des Autorenteams kann eine solche Einführung mehr oder weniger in die technische Tiefe gehen, oder sich eben stärker an den Rahmenbedingungen (Vor- und Nachteile, Verbreitung, proprietär/offener Standard etc.) orientieren.

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Marc Reichelt]

Hallo Felix,

SELFHTML 9.0 wird also endlich etwas aktueller. Und natürlich gibt es bei Flash wesentlich bessere Ressourcen als es bei SELFHTML geben wird - aber gibt es das bei PHP nicht auch? Oder Datenbanken?

und damit würde SelfHTML 9 seiner eigenen Tradition treu bleiben, indem es in diese Web-Technologien einführt, die wesentlichen Merkmale, Eigenschaften und Einsatzmöglichkeiten beschreibt und auf weiterführende Resourcen verweist. Je nach Gutdünken des Autorenteams kann eine solche Einführung mehr oder weniger in die technische Tiefe gehen, oder sich eben stärker an den Rahmenbedingungen (Vor- und Nachteile, Verbreitung, proprietär/offener Standard etc.) orientieren.

und genau das denke ich mir beim SWF-Format auch.
Der Teil von ActionScript bleibt ebenfalls nur eine Einführung, und danach wird auf weiterführende Quellen verwiesen.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Richard Rüfenacht]

Hallo Marc!

Natürlich sollte es für das Tool von Macromedia eine Seite geben, die allerdings auch auf die OpenSource-Alternativen hinweist. Im Grunde stelle ich mir eine solche Struktur vor:

+------------------+
                 ------| Macromedia Flash |-----
+----------+     |     +------------------+    |     +------------------+
| Einstieg |-----|                             |-----| ActionScript 2.0 |
+----------+     |     +------------------+    |     +------------------+
                 ------| OpenSource-Tools |-----
                       +------------------+

D.h. es gibt erst einen zentralen Einstieg, der auf die Unterschiede zwischen den beiden eigentlichen Einführungen hinweist.

Irgendwie vermisse ich eine dritte Gruppe, nämlich all die vielen Tools, die ebenfalls *.swf Dateien erzeugen können. Einige sind kostenlos, andere mehr oder weniger preiswert. Ich meine, in der Einleitung sollte zunächst klar gemacht werden, dass *.swf nicht einfach Flash ist, da scheint mir ein sprachliches Problem zu bestehen. Die Kernaussage: um *.swf zu erstellen, wird nicht unbedingt Macromedia Flash benötigt.

Die beiden Einführungen dann zeigen die Grundprinzipien der Tools - und sollen prinzipiell dazu dienen, dem Leser zu zeigen, wo ActionScript ins Spiel kommt, mit einigen grundlegenden Beispielen.

Die Beschreibung von Macromedia Flash und eventuell noch weiterer Tools halte ich für nicht realisierbar und auch nicht für sinnvoll in dieser Flash feindlichen Umgebung. Ich halte eine klare Gewichtung zu Gunsten von OpenSource für besser zu SELFHTML passend und auch besser einem breiten Informationsbedürfnis in dieser Richtung angemessen. Es sollte klar werden, dass das etwas missverständliche Gerede von *Flash* nicht unbedingt das Tool *Macromedia Flash* meinen muss. Das - wie ich finde - wichtigste Tool der OpenSource-Szene für *.swf hast du noch gar nicht erwähnt: ECLIPSE. Dazu gibt es z.B. das AS2-Plugin ASDT und andere.

Denn ActionScript macht Flash erst richtig dynamisch, damit kann man viele Dinge erledigen: Sounds (MP3) und Videos (FLV) laden und abspielen, XML-Daten parsen, mit Server kommunizieren, etc.
Der letzte (und wichtigste!) Teil ist dann der mit ActionScript, der ja unabhängig von dem verwendeten Tool geschrieben werden kann.

Irgendwie habe ich bei deiner ActionScript-Interpretation kein so gutes Gefühl. Alles in Flash ist ActionScript, die Frage ist nur, ob die Scripte schon fertig sind, oder ob die geschrieben werden müssen. Viele Tools, die *.swf Dateien erstellen können, greifen auf vorgefertigte Scripts zurück, auch Macromedia Flash selbst.

Mit prinzipiellen Beispielen, und zuletzt ein Verweis auf die aktuellste ActionScript-Referenz.

Auf die Beispiele bin ich besonders gespannt. ;-)

Das Ziel für SELFHTML sollte für mich auf jeden Fall darin bestehen, Dinge mit Flash aufzuzeigen, die mit den heutigen Mitteln einfach nur schlecht realisierbar sind (siehe EMFF).

Da setzt du dir aber hohe Ziele. Eigentlich würde es schon genügen, wenn einige grundsätzliche Missverständnisse ausgeräumt würden. Dazu eine Aussage, die der als Flash Kritiker bekannte Usability-Guru Jakob Nilsen kürzlich in einem Interview gemacht hat: "Flash kann gut eingesetzt werden. Ich habe einige tolle Konfigurationswerkzeuge und sogar Warenkörbe mit vollständigem Checkout in Flash-Technik gesehen, die flüssiger zu bedienen waren , als der klassische seitenbasierte Ansatz." [MX Magazin 10/2005 S.38]

Beste Grüsse
Richard

[Marc Reichelt]

Hallo Richard,

D.h. es gibt erst einen zentralen Einstieg, der auf die Unterschiede zwischen den beiden eigentlichen Einführungen hinweist.
Irgendwie vermisse ich eine dritte Gruppe, nämlich all die vielen Tools, die ebenfalls *.swf Dateien erzeugen können. Einige sind kostenlos, andere mehr oder weniger preiswert. Ich meine, in der Einleitung sollte zunächst klar gemacht werden, dass *.swf nicht einfach Flash ist, da scheint mir ein sprachliches Problem zu bestehen. Die Kernaussage: um *.swf zu erstellen, wird nicht unbedingt Macromedia Flash benötigt.

Das ist eine gute Kernaussage, darf ich die übernehmen, falls ich die Aufgabe bekommen würde, den Flash-Teil zu schreiben? :-)

Die Beschreibung von Macromedia Flash und eventuell noch weiterer Tools halte ich für nicht realisierbar und auch nicht für sinnvoll in dieser Flash feindlichen Umgebung. Ich halte eine klare Gewichtung zu Gunsten von OpenSource für besser zu SELFHTML passend und auch besser einem breiten Informationsbedürfnis in dieser Richtung angemessen. Es sollte klar werden, dass das etwas missverständliche Gerede von *Flash* nicht unbedingt das Tool *Macromedia Flash* meinen muss. Das - wie ich finde - wichtigste Tool der OpenSource-Szene für *.swf hast du noch gar nicht erwähnt: ECLIPSE. Dazu gibt es z.B. das AS2-Plugin ASDT und andere.

Ich habe es mir soeben angesehen, ist ganz cool. Allerdings ist es auch schon ziemlich komplex - ich würde in der Einführung von einfachen Textdateien ausgehen, die dann von der Konsole aus (MTASC und swfmill) eingelesen und daraus die swf-Dateien produziert werden. Ein Hinweis oder gar eine kurze Einleitung in dieses ASDT finde ich aber auf jeden Fall angebracht.

Der letzte (und wichtigste!) Teil ist dann der mit ActionScript, der ja unabhängig von dem verwendeten Tool geschrieben werden kann.
Irgendwie habe ich bei deiner ActionScript-Interpretation kein so gutes Gefühl. Alles in Flash ist ActionScript, die Frage ist nur, ob die Scripte schon fertig sind, oder ob die geschrieben werden müssen. Viele Tools, die *.swf Dateien erstellen können, greifen auf vorgefertigte Scripts zurück, auch Macromedia Flash selbst.

Auf fertige Code-Blöcke kann man bei jeder Programmiersprache zurückgreifen. Mir geht es um kurze, "knackige" Beispiele - und eben eine kurze Einführung in ActionScript 2.0.

Mit prinzipiellen Beispielen, und zuletzt ein Verweis auf die aktuellste ActionScript-Referenz.
Auf die Beispiele bin ich besonders gespannt. ;-)

Das Schöne ist, dass sich bei Flash mit wenig Code beeindruckende Beispiele erzeugen lassen. :-)

Das Ziel für SELFHTML sollte für mich auf jeden Fall darin bestehen, Dinge mit Flash aufzuzeigen, die mit den heutigen Mitteln einfach nur schlecht realisierbar sind (siehe EMFF).
Da setzt du dir aber hohe Ziele. Eigentlich würde es schon genügen, wenn einige grundsätzliche Missverständnisse ausgeräumt würden. Dazu eine Aussage, die der als Flash Kritiker bekannte Usability-Guru Jakob Nilsen kürzlich in einem Interview gemacht hat: "Flash kann gut eingesetzt werden. Ich habe einige tolle Konfigurationswerkzeuge und sogar Warenkörbe mit vollständigem Checkout in Flash-Technik gesehen, die flüssiger zu bedienen waren , als der klassische seitenbasierte Ansatz." [MX Magazin 10/2005 S.38]

Das hat der wirklich gesagt? Irgendwie kann ich das kaum glauben... *g*
In etwa so habe ich mir das gedacht. Vor allem aber sollte die Einführung zeigen, was mit Flash besser nicht gemacht wird.

Irgendwie glaube ich, dass ich mir schon fast selbst ein <I> zugespielt habe. Dabei ist das doch momentan so ungünstig, weil ich schon 30 andere <I>s habe... :-(
(d.h. eigentlich habe ich bei 30 aufgehört zu zählen)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[molily]

Hallo Gerd,

vielen Danke für dein Lob und deinen Vorschlag.

Jetzt aber doch ein Kritikpunkt:
Da ja AJAX (synchronous Javascript and XML) in letzter Zeit in aller Munde ist, und die Gestaltung, Design und nicht zuletzt die Usability einer Webseite entscheidend beeinflussen kann, verstehe ich nicht ganz wieso dieses Thema auch jetzt beim Update völlig vernachläßigt worden ist.

Ja, der Einsatz von JavaScript für Webanwendungen ist ein Thema, das in SELFHTML momentan völlig fehlt. Das liegt aber nicht daran, dass wir dieses und die vielen anderen fehlenden Themen absichtlich vernachlässigen und für nicht relevant halten.

SELFHTML 8.1.1 ist zunächst einmal ein Update, das lediglich kleine Fehler korrigiert. Im Bereich JavaScript gab es einige Übarbeitungen, es kamen aber (abgesehen von ein, zwei Eigenschaften und Methoden von bereits dokumentierten Objekten) keine neuen Inhalte hinzu. SELFHTML 8.1.x basiert im Grunde noch auf SELFHTML 8.0 aus dem Jahr 2001. So gibt es z.B. immer noch kein Kapitel über OOP (prototypische Vererbung usw.). Oder eine hinreichende Dokumentation von DOM Events. Oder DOM Style. Oder JavaScript und XML (DOMParser, XMLSerializer usw. sowie Äquivalente). Oder ein paar Worte zu E4X. Die Liste ist eigentlich unendlich lang.

Das sind alles wichtige Themen, die wir künftig behandeln wollen. Wie du vielleicht mitbekommen hast, planen wir an einer neuen Version 9. Dort wird diese Einsatzweise von JavaScript und die zugehörigen Objekte wie XMLHttpRequest höchstwahrscheinlich angesprochen.

Mathias