Vorläufige Endversion meines Artikels

[Felix Riesterer]

Liebe Kritiker,

nun habe ich lange an meinem hier im Forum angefangenen Artikel gearbeitet, immer wieder unterstützt durch die Redaktion von SELFHTML, und nun möchte ich mir öffentliche Kritiken einholen.

Ich habe den Artikel hier hochgeladen: Fader Framework

Nun meine Fragen:

1.) Ist der Aufbau des Artikels für einen Laien nachvollziehbar?
2.) Ist die Progression der Komplexität in den Beispielen von Anfängern zu bewältigen?
3.) Wo vermisst Ihr Hintergrundinformationen (oder Links dazu) in diversen Teilen?
4.) Kann jedes Beispiel technisch in Euren Browsern nachvollzogen werden?
5.) Sonstiges?

Bin mal gespannt, ob sich wer dafür interessiert... ;-) Vielen Dank schonmal im Voraus!

Liebe Grüße,

Felix Riesterer.

[hawkmaster]

Hallo Felix,

ich habe dein Tutorial einmal überflogen.
Zuerst einmal "Hut ab" für so viel Engagement und tolle Infos.

Ich verstehe mich schon noch als JS Laie und werde mich mal den Artikel und das Thema ausführlich durchlesen.

Auf den ersten Eindruck sieht es sehr übersichtlich aus. Auch haben die Beispiele in meinem FF3 gut funktioniert.

Falls mir was auffällt werde ich dir nochmals bescheid geben
viele Grüße
hawk

[Felix Riesterer]

Lieber hawkmaster,

vielen Dank für Dein Lob! Freut mich, wenn Dir der Artikel zusagt.

Anscheinend ist es Dir in der kurzen Zeit nicht möglich gewesen, die steigende Komplexität des Artikels irgendwie zu beurteilen - aber ich freue mich, wenn Dir der Artikel Lust macht, sich damit zu beschäftigen.

Vielen Dank für Deine Antwort!

Liebe Grüße,

Felix Riesterer.

[suit]

1.) Ist der Aufbau des Artikels für einen Laien nachvollziehbar?

nein, der artikel ist imho bei weitem zu lange und der aufbau (sprich das inhaltsverzeichnis schockiert)

2.) Ist die Progression der Komplexität in den Beispielen von Anfängern zu bewältigen?

ja

4.) Kann jedes Beispiel technisch in Euren Browsern nachvollzogen werden?

funktioniert bei mir einwandfrei

wie siehts mit MozOpacity für alle mozilla-browser und KhtmlOpacity für alte safaris aus?

5.) Sonstiges?

ich würde es in zwei artikel aufteilen

1x einen "einfachen" fader und 1x die ojektorientierte variante - der artikel ist so meiner meinung nach viel zu lang (sage ich schon), das liest keiner mehr ab etwa der hälfte

[Felix Riesterer]

Lieber suit,

1.) Ist der Aufbau des Artikels für einen Laien nachvollziehbar?
nein, der artikel ist imho bei weitem zu lange und der aufbau (sprich das inhaltsverzeichnis schockiert)

da hast Du sicherlich Recht. Ich werde das mit der Redaktion klären. Malcoms Hinweis zu Vinzenz' Artikel entspricht wohl dem, was Du auch schon gemeint hast?

2.) Ist die Progression der Komplexität in den Beispielen von Anfängern zu bewältigen?
ja

Danke. Das hilft mir weiter.

wie siehts mit MozOpacity für alle mozilla-browser und KhtmlOpacity für alte safaris aus?

Nachdem Benutzer des FF2 mit dem automatischen Update auf den FF3 umgerüstet werden (sollen), sehe ich in meinem Artikel keinen Grund, alte Browserversionen großartig zu unterstützen. Wer Opera einsetzt, der hat sicherlich auch einen "neuen", der opacity versteht. Konqueror ist meines Wissens ein Webkit-Browser, der das auch kann (zumindest mein Safari unter Windoof konnte alles) - also wozu die zusätzliche Mühe?

5.) Sonstiges?
ich würde es in zwei artikel aufteilen

Da bin ich mir jetzt nicht so sicher. Malcoms Idee mit der Segmentierung des Artikels in Kapitel, die eigene Unterseiten haben, könnte schon genügend helfen - wie gesagt, das erörtere ich noch mit der Redaktion. Aber Dein Impuls in dieser Richtung zeigt mir, das das Anliegen ein ziemlich wichtiges ist.

1x einen "einfachen" fader und 1x die ojektorientierte variante - der artikel ist so meiner meinung nach viel zu lang (sage ich schon), das liest keiner mehr ab etwa der hälfte

Es muss auch niemand den Artikel "am Stück" lesen. Der Artikel soll vielmehr einen Anfänger Schritt für Schritt tiefer in die Struktur führen, bei der er jederzeit stehenbleiben darf, um nach einiger Zeit, wenn er das Bisherige "verdaut" hat, wieder anzusetzen, um seine Scripte noch besser und vielseitiger zu konstruieren. Von daher sehe ich das Pensum schon als gerechtfertigt, wenn man aber auch über die "Portionierung" noch sprechen muss.

Vielen Dank für Dein Feedback! Über Deine Impulse werde ich auf jeden Fall noch eine Weile nachdenken müssen.

Liebe Grüße,

Felix Riesterer.

[suit]

da hast Du sicherlich Recht. Ich werde das mit der Redaktion klären. Malcoms Hinweis zu Vinzenz' Artikel entspricht wohl dem, was Du auch schon gemeint hast?

jein - ich hatte eher gemeint, das ganze in zwei separate unterschiedliche artikel zu teilen

einen einfachen für einsteiger und einen gefinkelteren, der auf dem anderen aufbaut für fortgeschrittene (der dann die objektorientierte variante behandelt)

also wozu die zusätzliche Mühe?

weils nur zwei zeilen sind ;)

Da bin ich mir jetzt nicht so sicher. Malcoms Idee mit der Segmentierung des Artikels in Kapitel, die eigene Unterseiten haben, könnte schon genügend helfen - wie gesagt, das erörtere ich noch mit der Redaktion. Aber Dein Impuls in dieser Richtung zeigt mir, das das Anliegen ein ziemlich wichtiges ist.

meine erfahrung hat gezeigt, dass viele leute lieger 3 kleine happen lesen als einen der so groß ist wie alle drei zusammen - ein psychologischer effekt? ;)

von der seite schockiert das inhaltsverzeichnis schon etwas ;)

Es muss auch niemand den Artikel "am Stück" lesen.

eben, genau darum sollte das ganze in grobe kapitel unterteilt werden - ggf will jemand einfach später einsteigen, warum auch immer

[Felix Riesterer]

Lieber suit,

jein - ich hatte eher gemeint, das ganze in zwei separate unterschiedliche artikel zu teilen

einen einfachen für einsteiger und einen gefinkelteren, der auf dem anderen aufbaut für fortgeschrittene (der dann die objektorientierte variante behandelt)

das widerspricht meiner Absicht, allen Anfängern (egal wie "fortgeschritten" sie sind) gerecht zu werden, indem sie da einsteigen, wo es für sie interessant wird, und dort aussteigen, wo sie fürs erste nicht mehr mitkommen. Im Grunde möchte ich, dass jeder Anfänger (nach seiner individuellen Zeit, die er braucht) am Ende des Artikels ankommen kann. Und das mit fließend steigender Komplexität. Keinesfalls soll es eine Zwei-Klassen-Version geben, bei der "Dummies" erstmal den "Dummy"-Artikel lesen "müssen", um dann nach einer rituellen Waschung den "erleuchteten" Artikel in Angriff nehmen dürfen.

Ich habe absichtlich stark überzeichnet, um meinen Standpunkt deutlicher zu machen, nicht aber um Deinen Vorschlag zu verhöhnen...

Da bin ich mir jetzt nicht so sicher. Malcoms Idee mit der Segmentierung des Artikels in Kapitel, die eigene Unterseiten haben, könnte schon genügend helfen - wie gesagt, das erörtere ich noch mit der Redaktion. Aber Dein Impuls in dieser Richtung zeigt mir, das das Anliegen ein ziemlich wichtiges ist.

meine erfahrung hat gezeigt, dass viele leute lieger 3 kleine happen lesen als einen der so groß ist wie alle drei zusammen - ein psychologischer effekt? ;)

von der seite schockiert das inhaltsverzeichnis schon etwas ;)

Das könnte man verschlanken, indem die Unterkapitel (also die eingerückten Links im Inhaltsverzeichnis) nur auf der Seite auftauchen, auf der sie auch nachlesbar sind. Ich könnte mir eine seitenweise Auftrennung anhand der Kapitel vorstellen. Das sollte die Happen deutlich verkleinern.

eben, genau darum sollte das ganze in grobe kapitel unterteilt werden - ggf will jemand einfach später einsteigen, warum auch immer

Und das könnte dieser jemand dann auch, da er sich an den Kapiteln orientiert, auf die entsprechende Seite navigiert, um dort im passenden Unterverzeichnis weiterzulesen.

Wie schon gesagt, ich werde das auch (und vor allem) mit der SEFLHTML-Redaktion besprechen. Die haben sicherlich auch Ihre durch Erfahrung gestützte Meinung dazu... ;-)

Liebe Grüße,

Felix Riesterer.

[suit]

Ich habe absichtlich stark überzeichnet, um meinen Standpunkt deutlicher zu machen, nicht aber um Deinen Vorschlag zu verhöhnen...

schon klar - hier scheiden sich aber wohl die geister ;) ich bin eher der typ der einen artikel für dummies haben will und wenn ich den kapiert habe, ist es mir viel einfacher möglich, die komplexeren zusammenhänge zu verstehen

Wie schon gesagt, ich werde das auch (und vor allem) mit der SEFLHTML-Redaktion besprechen. Die haben sicherlich auch Ihre durch Erfahrung gestützte Meinung dazu... ;-)

ich bin langsam für ein bullshit-bingo in diesem thread, als begriffe schlage ich "redaktion" und "besprechen" vor ;) SCNR

[Gunnar Bittersmann]

@@Felix Riesterer:

wie siehts mit MozOpacity für alle mozilla-browser und KhtmlOpacity für alte safaris aus?

Nachdem Benutzer des FF2 mit dem automatischen Update auf den FF3 umgerüstet werden (sollen)

Schon FF2 versteht 'opacity'.

sehe ich in meinem Artikel keinen Grund, alte Browserversionen großartig zu unterstützen.

ACK.

Was mir auffiel:

„Die CSS-Eigenschaft opacity steuert die "Transparenz" eines Elements“

ist missverständlich; Opazität ist ja gerade das Gegenteil von Transparenz.

„Um Missverständnissen vorzubeugen, […]“

Siehste!

„[…] sollte man jedoch eher von der "relativen Sichtbarkeit" […]“

Wie bitte? Was bitte?

„[…] oder "Deckkraft" eines Elements sprechen.“

Warum nicht gleich so? Warum erst zweimal rumfaseln, anstatt gleich den Kern treffen? BTW, den Begriff „Opazität“ gibt’s auch im Deutschen.

Die Stelle könnte lauten:
„Die CSS-Eigenschaft opacity steuert die Deckkraft (Opazität) eines Elements. Es gilt: Je höher der Wert, desto weniger durchsichtig (transparent) ist ein Element. […]“

„Beispiel für Transparenz mittels opacity“

Ändern in „Beispiel für Deckkraft mittels opacity“?

„• Dieser Smiley wird ohne opacity dargestellt“

Nein, „ohne“ hieße ja 'opacity: 0', also völlig transparent. Das Gegenteil ist der Fall. Du meinst „ohne spezielle Angabe für 'opacity'“, also den Defaultwert 'opacity: 1'.

Live long and prosper,
Gunnar

[Felix Riesterer]

Lieber Gunnar,

Danke für Deine treffenden Hinweise zur Nomenklatur von "Transparenz" und "Deckkraft" bzw. Opazität. Auch wenn ich diesem schräußlichen Wort noch nie begegnet bin, so ist trotzdem meine bisherige Benennung unvorteilhaft.

Die Stelle könnte lauten:
„Die CSS-Eigenschaft opacity steuert die Deckkraft (Opazität) eines Elements. Es gilt: Je höher der Wert, desto weniger durchsichtig (transparent) ist ein Element. […]“

„Beispiel für Transparenz mittels opacity“

Ändern in „Beispiel für Deckkraft mittels opacity“?

„• Dieser Smiley wird ohne opacity dargestellt“

Nein, „ohne“ hieße ja 'opacity: 0', also völlig transparent. Das Gegenteil ist der Fall. Du meinst „ohne spezielle Angabe für 'opacity'“, also den Defaultwert 'opacity: 1'.

Wird verbessert (nur nicht mehr heute abend)! Danke!

Liebe Grüße,

Felix Riesterer.

[suit]

Danke für Deine treffenden Hinweise zur Nomenklatur von "Transparenz" und "Deckkraft" bzw. Opazität. Auch wenn ich diesem schräußlichen Wort noch nie begegnet bin, so ist trotzdem meine bisherige Benennung unvorteilhaft.

fürs protokoll:
man darf opaziät bzw transparenz nicht mit transluzenz verwechseln - transluzente dinge sind zwar wie (nicht vollständig) opake dinge partiell lichtdurchlässig - im gegensatz dazu bietet transluzenz diffuse komponente (volumenstreuung)

das ganze lässt sich mit css aber leider nicht umsetzen (obwohls coole einsatzgebiete dafür gäbe) - allerdings gibts ein paar microsoft-filter die sich dafür missbrauchen lassen blur mit opacity kombiniert ergibt zumindest eine schlechte näherung zu echtem sub surface scattering

[Malcolm Beck´s]

hi Felix,

ich muss auch erstmal meinen Hut zücken, tolle arbeit, und wenn ich die Zeit finde, werde ich mich mal dran versuchen, sieht jedenfalls sehr gut aus.

1.) Ist der Aufbau des Artikels für einen Laien nachvollziehbar?

Ich hab ihn nur kurz überfliegen können, sah aber verständlich aus, nur, wie von suit schon angemerkt, etwas viel auf einen schlag.
Vielleicht wäre ein Aufbau wie Vinzenz Artikel Übersichtlicher.

4.) Kann jedes Beispiel technisch in Euren Browsern nachvollzogen werden?

Ich verstehe diese Demo nicht, bei mir funktioniert Start/Stop nicht, es wird weiter gefadet.

Die anderen Funktionen können leider nicht nachvollzogen werden, da man weder die Reihenfolge der Bilder, noch deren Anzahl kennt bzw. sieht.

5.) Sonstiges?

Schön! :)

Bin mal gespannt, ob sich wer dafür interessiert... ;-)

Das definitiv.

mfg

[Felix Riesterer]

Lieber Malcolm,

danke für Dein großes Lob. Das tut gut, denn die Redaktion überlässt diesen Teil eines Feedbacks anderen - natürlich zu Recht.

nur, wie von suit schon angemerkt, etwas viel auf einen schlag.
Vielleicht wäre ein Aufbau wie Vinzenz Artikel Übersichtlicher.

Zugegeben. Vielleicht ist eine Unterteilung in mehrere Seiten sinnvoll. Das kläre ich mit der Redaktion.

Ich verstehe diese Demo nicht, bei mir funktioniert Start/Stop nicht, es wird weiter gefadet.

Ja, ich sollte eine schnellere Überblendung voreinstellen. Mit start bzw. stop wird nur der Bilderwechsel gestoppt, nicht jedoch eine gerade ablaufende Überblendung. Stelle als fadeStep einfach mal 2 ein. Dann wird es klarer.

Die anderen Funktionen können leider nicht nachvollzogen werden, da man weder die Reihenfolge der Bilder, noch deren Anzahl kennt bzw. sieht.

Dann stelle nicht nur fadeStep auf 2, sondern die viewTime auch auf 1000. Dann geschehen die Wechsel sehr flott, sodass man die Reihenfolge schneller wahrnehmen kann.

Bin mal gespannt, ob sich wer dafür interessiert... ;-)

Das definitiv.

Freut mich zu lesen. Danke für Deine Impulse. Sie werden auf jedenfall weiter bedacht.

Liebe Grüße,

Felix Riesterer.

[Malcolm Beck´s]

hi,

danke für Dein großes Lob. Das tut gut, denn die Redaktion überlässt diesen Teil eines Feedbacks anderen - natürlich zu Recht.

Ein Offizielles Danke auch auf entsprechenden Seiten sollte nicht fehlen, wenn man denn frei verfügbare Scripte voll oder auch nur zu teilen nutzt.

Ja, ich sollte eine schnellere Überblendung voreinstellen. Mit start bzw. stop wird nur der Bilderwechsel gestoppt, nicht jedoch eine gerade ablaufende Überblendung. Stelle als fadeStep einfach mal 2 ein. Dann wird es klarer.

Ahh, ok, das habe ich wohl beim überfliegen überlesen, jetzt funktioniert auch das.

Dann stelle nicht nur fadeStep auf 2, sondern die viewTime auch auf 1000. Dann geschehen die Wechsel sehr flott, sodass man die Reihenfolge schneller wahrnehmen kann.

Wäre es nicht möglich, alle Smileys, die in dem Script vorkommen auch auf der Seite direkt anzuzeigen?
So könnte man sehen, welche Bilder vorkommen und kann so den Fade besser nachvollziehen. Nur so ne Idee.

mfg

[Felix Riesterer]

Lieber Malcolm,

Ein Offizielles Danke auch auf entsprechenden Seiten sollte nicht fehlen, wenn man denn frei verfügbare Scripte voll oder auch nur zu teilen nutzt.

... oder auf ihre Artikel (molily) verweist. Das muss ich allerdings unbedingt nachholen. Das stimmt.

Liebe Grüße,

Felix Riesterer.

[Struppi]

Mann oh Mann, wie kann man so viel schreiben, würd ich auch gern können ;-)

Aber du wolltest Kritik .

5.) Sonstiges?

Einmal nennst du den Konstruktor immer noch Fabrik. Das mag zum Laienhaften veranschaulichen ein attraktiver Begriff sein, er ist aber in mehrerer Hinsicht falsch. Einmal stößt einem als Nichtlaie die Parallelität zur Begriff des  Entwurfsmusters der Fabrikmethode auf. Ein Konstruktor ist gerade keine Fabrikmethode, damit versuchst du sogar im gegenteil einen Konstruktor zu vermieden. Dann ist jede Funktion in Javascript ein Konstruktor. Ich würd' es etwas anders formulieren, in etwa so:

Objekte mit einem Konstruktor erzeugen

In Javascript ist jede Funktion ein Konstruktor, mit dem Schlüsselwort new erzeugt man Kopien von dem Typ des Konstruktors und die Konstruktorfunktion wird aufgerufen - das Objekt initialisiert.

function Konstruktor (wert) {
    this.produkt = wert;
}

var meinObjekt = new Konstruktor ("meinWert");

alert(meinObjekt.produkt); // erzeugt die Meldung "meinWert"

Erläuterung:

Eine Konstruktor-Funktion gibt als "Ergebnis" eine neue Instanz eines Objektes zurück, wenn man sie mit dem Schlüsselwort new aufruft (meinObjekt = new Konstruktor()). In der Konstruktorfunktion ist das das Schlüsselwort this die Referenz auf das aktuelle Objekt, in dem Beispiel also später auf meinObjekt. Da beim erzeugen des Objektes die Konstruktorfunktion aufgerufen wird, können dort Parameter, wie bei einer normalen Funktion übergeben werden. Dann wird dieser Parameter der Objekteigenschaft produkt zugewiesen. Das aktuelle Objekt meinObjekt hat nun die Eigenschaft produkt mit dem wert meinWert.

Weiter:

Du schreibst:

Als Ersatz für das ursprüngliche Bild kommt sinvollerweise ein <span>-Element zum Einsatz, das anstelle des ursprünglichen Bildes in das HTML-Dokument eingesetzt wird. Dieses <span>-Element ist ebenso ein Inline-Element wie das ursprüngliche Bild es gewesen ist, sodass die Logik der Dokumentstruktur nicht gestört wird.

Ich weiß nicht ob das wirklich eine Rolle spielt, mit der Logik. Ich weiß nicht, ob es die Diskussion hier schon mal gab. Aber ich glaube, du musst bei mit JS eingefügten Elementen, nicht unbedingt die Regeln des HTML Validators befolgen. Aber das ist nur meine Meinung, da kann ich mich auch Irren.

Dann schreibst du später, im zusammenhang mit appendChild und replaceChild:

Solche Manipulationen am DOM-Baum des HTML-Dokuments sind erst nach dem abgeschlossenen Ladevorgang möglich!

Soweit ich das sehe ist das nicht so. Du kannst solche Manipulationen auch nach dem schliessendem Element im HTML Code machen. Das geht vermutlich bei dir nicht, da du evtl. auf document.body zugreifst. Aber bei meiner sortierbaren Tabelle geht's.

Ein Kritikpunkt, den du dir nochmal überlegen solltest und der ja auch schon diskutiert wurde, ist, ob du wirklich ein new Boolean im Fehlerfall zurückgeben willst? Das ist sehr unüblich und es gibt bessere Wege. z.b. könntest du auf die Eigenschaft element testen.

Dann will ich natürlich nicht abreden, dass du es bestimmt versucht hast, aber ich finde deine Erläuterungen zu den CSS Problemen zu hart. Einmal bin ich nicht sicher ob es wirklich so kompliziert ist (mit den inline-table, eine Eigenschaft die ich noch nie verwendet habe) und dann ist das schon relativ sehr fortgeschritten was du da erläuterst. Dazu sind mehr als Grundlagen in CSS nötig, um das nachzuvollziehen .

Es gibt sicher noch hier und da Stellen, wo ich deine umfangreichen Erläuterungen straffen würde oder auch eine andere Richtung eingeschlagen hätte, aber ich will ja auch nicht zuviel mäkeln und schon gar nicht so einen Artikel selber schreiben müssen ;-)
Aber eins noch, da du am Anfang auf den Artikel von Mathias verweist (der Link ist übrigens falsch), dann benutz doch auch literale, du benutzt ein Misch Masch aus beiden Schreibweisen.

So, ich hoffe das war nicht zuviel.

Struppi.

[Felix Riesterer]

Lieber Struppi,

vielen herzlichen Dank für Dein umfangreicheres Feedback! Ich habe mir die Zeit genommen, Deine Anregungen in meinen Artikel einzuarbeiten.

Mann oh Mann, wie kann man so viel schreiben, würd ich auch gern können ;-)

Irgendwie muss meine akademische Ausbildung bei mir ja Spuren hinterlassen haben... oder? ;-)

Aber du wolltest Kritik .

Jaaa!

Einmal nennst du den Konstruktor immer noch Fabrik. [...]
Ich würd' es etwas anders formulieren

Deine Vorschläge habe ich übernommen und eingearbeitet.

Ich weiß nicht ob das wirklich eine Rolle spielt, mit der Logik. Ich weiß nicht, ob es die Diskussion hier schon mal gab. Aber ich glaube, du musst bei mit JS eingefügten Elementen, nicht unbedingt die Regeln des HTML Validators befolgen. Aber das ist nur meine Meinung, da kann ich mich auch Irren.

Warum sollte ich eine logische Dokumentenstruktur mittels JS "zerstören"? Wenn ich mich da an den sinnvollen Aufbau halte, dann klappen solche Manipulationen vielleicht auch in XML-Dokumenten (z.B. XHTML als application/xhtml+xml ausgeliefert), ohne dass der Browser sofort alles zusammenfaltet... Jedenfalls will ich solche Risiken erst garnicht eingehen.

Solche Manipulationen am DOM-Baum des HTML-Dokuments sind erst nach dem abgeschlossenen Ladevorgang möglich!

Soweit ich das sehe ist das nicht so.

Auch hier habe ich jetzt eine genauere Formulierung dazu:

"Solche Manipulationen am DOM-Baum des HTML-Dokuments sind erst dann möglich, wenn die zu manipulierenden Elemente auch tatsächlich zum Zeitpunkt des Funktionsaufrufes im Dokument existieren. Aus diesem Grund ist es mehr als ratsam, solche Manipulationen erst nach dem abgeschlossenen Ladevorgang durchzuführen! Daher kann die Funktion ersetze auch erst nach dem vollständigen Laden fehlerfrei Arbeiten."

Ein Kritikpunkt, den du dir nochmal überlegen solltest und der ja auch schon diskutiert wurde, ist, ob du wirklich ein new Boolean im Fehlerfall zurückgeben willst? Das ist sehr unüblich und es gibt bessere Wege. z.b. könntest du auf die Eigenschaft element testen.

Meinst Du das so, dass ich in meinem Konstruktor einfach ein simples "return;" notiere, anstatt ein new Boolean(false)? Das ließe sich sehr einfach ändern, ja.

Dann will ich natürlich nicht abreden, dass du es bestimmt versucht hast, aber ich finde deine Erläuterungen zu den CSS Problemen zu hart.

Ich habe die Erläuterung aufgetrennt in "nimm es hin, es funzt" und in "für Fortgeschrittene, die es wirklich wissen wollen", damit Anfänger das zweitere einfach überlesen können. Besser so?

Aber eins noch, da du am Anfang auf den Artikel von Mathias verweist (der Link ist übrigens falsch), dann benutz doch auch literale, du benutzt ein Misch Masch aus beiden Schreibweisen.

Den Link habe ich korrigiert - danke. Dass ich hier zweierlei Notationen vermische hat zwei Gründe:
1.) Ich notiere gerne Objektliterale. Eine Funktionsdefinition kann ich nicht als Objektliteral notieren.
2.) Um Anfängern beide Notationen anzubieten und näherzubringen, benutze ich eben beide. Dass man das Objekt auch anders hätte notieren können, mag sein, führt aber meiner Meinung nach zu längerem Code, der nicht unbedingt übersichtlicher sein muss.

Jedenfalls vielen Dank für Deine Anregungen! Mein Artikel ist dadurch bestimmt besser geworden!

Liebe Grüße,

Felix Riesterer.

[frankx]

Hellihello Felix,

gestern wollte ich dir direkt antworten, da war aber irgendwie das Forum plötzlich unerreichbar, also heute:

fein das, viel zu lesen, sieht so übersichtlich aus, dass mans wohl genauer studieren muss, um hilfreich zu sein. Da ich mich z.Z. für das ZendFramework interessiere, fragte ich mich just beim Überflug Deines Artikels, ob ein selbiger übers ZFW für Selfhtml interssant wäre. So arg viel gibts dazu (momentan) ja noch nicht. Gleicher Aufbau wie bei Dir, "nur" anderer Inhalt  (ist übrigens auch "modular" (;-)).

Mittlerweile gibt es ja schon einige Kommentare hier, die ich mal sukkzessive studieren werde.

Dank und Gruß,

frankx

[molily]

Hallo,

Da ich mich z.Z. für das ZendFramework interessiere, fragte ich mich just beim Überflug Deines Artikels, ob ein selbiger übers ZFW für Selfhtml interssant wäre.

Ja klar, sehr gerne!

Mathias

[molily]

Hallo,

Da ich mich z.Z. für das ZendFramework interessiere, fragte ich mich just beim Überflug Deines Artikels, ob ein selbiger übers ZFW für Selfhtml interssant wäre.

Artikelvorlage (ZIP)
Code-Vorgaben (Codebeispiele für die Link-Icons zum Nachschlagen usw., die Vorlage sollte aber zum größten Teil selbsterklärend seni)

Mathias

[Christian Seiler]

Hallo Frank,

gestern wollte ich dir direkt antworten, da war aber irgendwie das Forum plötzlich unerreichbar,

Ja, da hat ein Switch gesponnen, musste rebootet werden. Nachdem sich bisher keiner drüber aufgeregt hat, habe ich es nicht für nötig gehalten, das irgendwo extra zu erwähnen.

Da ich mich z.Z. für das ZendFramework interessiere, fragte ich mich just beim Überflug Deines Artikels, ob ein selbiger übers ZFW für Selfhtml interssant wäre.

Sehr gerne, das wäre sehr cool. Ich finde ja sowieso, dass es viel zu wenig Artikel über ein paar moderne OOP-Techniken in PHP gibt (insbesondere Iteratoren, ArrayAccess, __get/__set und __call) - und da das ZF diese Techniken intensiv nutzt, wäre es ein sehr schöner weg, das den Leuten mal näher zu bringen und damit auch gleichzeitig zu zeigen, dass diese sinnvoll angewendet werden können.

Viele Grüße,
Christian

[frankx]

Hellihello Christian und molily,

Da ich mich z.Z. für das ZendFramework interessiere, fragte ich mich just beim Überflug Deines Artikels, ob ein selbiger übers ZFW für Selfhtml interssant wäre.

Sehr gerne, das wäre sehr cool. Ich finde ja sowieso, dass es viel zu wenig Artikel über ein paar moderne OOP-Techniken in PHP gibt (insbesondere Iteratoren, ArrayAccess, __get/__set und __call) - und da das ZF diese Techniken intensiv nutzt, wäre es ein sehr schöner weg, das den Leuten mal näher zu bringen und damit auch gleichzeitig zu zeigen, dass diese sinnvoll angewendet werden können.

Jau, das von Dir o.g. hatte ich auch vermisst. Ich dachte bis dahin immer, die Wesentlichen Web-Dinge würde ich durch Lektüre des Forums zumindest im Ansatz mitbekommen. Was ja zu 99% auch stimmt. Aber die magischen Methoden, Iteratoren, spl, und das darauf aufbauende ZF sind vermutlich erst noch im kommen. U.u. liegt es ja auch daran, dass sich das auch erst für etwas größere Webanwendungen lohnt. Immerhin finde ich es aber auch schön, mal einen Ansatz zu haben, wie das "best practice" oder eine Ordnerstruktur für eine klares MVC.

s.a. ,  darin sowie  angelehnt daran dann.

Mal schauen ob es mir gelingt, da die Grundansätze mal zusammenzuschrauben bzw. meinen bisherigen Gang der Erkenntnisgewinnung nachzuzeichnen. Ggf. auch an einem Beispiel, wie "Aufbau eines exemplarischen Webprojektes mit dem ZF" oder so. Da kommt man ja dann an den spl-Methoden und Iteratoren garnicht vorbei. Wobei mir ArrayAccess bisher zB. noch jarnüscht sagt. Immerhin aber schon eine eigene kleine Iterator-Implementation für eine mysqli-result zusammengewurstelt (s. obigen link (;-)).

Dank und Gruß,

frankx

[dedlfix]

echo $begrüßung;

[...] Wobei mir ArrayAccess [aus PHPs SPL] bisher zB. noch jarnüscht sagt.

Normalerweise hat man ja ein Objekt $foo und greift auf seine Eigenschaften mit -> zu: $foo->bar. Voraussetzung ist, dass der Name bar zur Programmierzeit bekannt ist. Ansonsten hampelt man mit variablen Variablen rum. Da tät sich $foo[$bar] anbieten, wenn man nicht $foo->get($bar) und $foo->set($bar, $value) notieren will.

Der Hauptanwendungszweck dürfte jedoch sein, dass man ein Array zur Datenablage haben möchte. Zur Pflege dieser Daten benötigt man Funktionalität, die man aber nicht an das Array binden kann. Also muss eine Klasse her, die Daten und Funktionalität bündelt. Wie greift man aber nun auf die Daten zu? Etwa so? $foo->get(42) Oder so? $foo->the_array[42] Warum nicht so? $foo[42]. Mit ArrayAccess ist letzteres möglich.

echo "$verabschiedung $name";

[Tim Tepaße]

Hallo Felix,

sorry fürs threaddriften und Nicht-Beantworten Deiner Fragen, aber beim Kurzen Überfliegen Deines Artikels ist mir eine Verbesserung eingefallen, die langfristig vielleicht relevant ist oder sich eventuell schon jetzt in einem ausgebautem, nicht nur zu pädagogischen Zwecken genutztem Fader-Framework eignen würde.

Apple hat zwei Erweiterungen von CSS gemacht, das pragmatischere CSS Transitions und das erweiterte CSS Animations. Beide beschäftigen sich mit der Animation der Veränderung von CSS-Eigenschaften über einen definierten Zeitraum, also z.B. die Animation von opacity von 0% bis 100% über einen Zeitraum von ein paar Sekunden. Beide sind wohl schon in Safari/iPhone implementiert, Transitions laufen für viele Eigenschaften schon im aktuellen Safari 3.1. In diesem Blog-Eintrag gibt es drei Beispiele, woanders gibt es eine nette Demo eines OS X Dock Effektes. Denkt man weiterhin darüber nach, gibt es viele nette Möglichkeiten dafür. CSS Transitions und Animations wurden recht gut von der CSS Working Group aufgenommen. Arbeit an den beiden wird wohl in die nächste Charta der CSS-WG geschrieben. Auch bei Mozilla scheint man sich dafür zu interessieren, aber wohl leider erst zu Gecko 2.0 (= c.a. Firefox 4) dazu zu kommen. Aber ich meine langfristig haben diese Ideen wohl eine Chance, zumindest Transitions, und bleiben nicht nur Apple-spezifische Eigenschaften, syntaktische Änderungen mal vorbehalten.

Würde ich so ein Fader-Framework basteln, würde ich durchaus überlegen, das zu integrieren. Der Vorteil liegt auf der Hand: In der normalen Lösung – dem schrittweisen runterzählen der opacity-Wertes – liegt viel Handlung bei Javascript. Dekrementieren und Zuweisen, damit die Rendering Engine neu rendert. Warten. Dekre ... wieder warten. Besonders das ständige Warten dürfte bei vielfältiger, diverser Nutzung von JS in dessen Einzel-Thread-Umgebung ziemlich nerven. Bei CSS Transitions setzt man dagegen einen Start-Wert, einen End-Wert und den Verlauf dazwischen. Den Start der Transition löst man durch eine Veränderung im DOM aus, z.B. durch setzen einer Klasse oder durch Eintreten eines Zustandes wie :hover. Das konkrete In- oder Dektrementieren dagegen wird von der Layout-Engine übernommen, JS ist also frei von vielem nervigen Einzelschritten.

Dies ist natürlich der Idealzustand, in einer Cross-Browser-Umgebung muss man immer noch die nervigere Direktmanipulation für Deppenbrowser machen. Der grundsätzliche Unterschied zwischen beiden Lösungswegen dürfte auch für pädagogische Zwecke nicht wirklich hilfreichen komplizierteren Quellcode sorgen. Dennoch: Es lohnt sich bei einem Browser noch nicht, bei zwei Implementierungen wäre ich aber schon dafür zu haben.

Tim

[Felix Riesterer]

Lieber Tim,

danke für Deinen Denkanstoß! Du hast völlig Recht, mein Konzept ist in Zukunft vielleicht durch solche Transitions irgendwann obsolet. Ich meine, dass auch molily mich auf entsprechende Möglichkeiten über die Filter im IE auf ähnliche Gedanken zu bringen versuchte...

bei zwei Implementierungen wäre ich aber schon dafür zu haben.

Gilt die filter-Eigenschaft im IE auch als "Implementierung"...? :-P

Ansonsten nennt sich der Artikel ja "kleiner Lehrgang zum vernünftigen Schreiben von JavaScripts" - und damit ist diese Fader-Geschichte eigentlich nur ein Vorwand (alias "konkreter technischer Anlass"), um objektorientiertes Schreiben, und das Zusammenfassen in ein Framework, vorzustellen. Ob das immer für jeden Bedarfsfall der Königsweg ist, sei dahingestellt.

Liebe Grüße,

Felix Riesterer.

[Felix Riesterer]

Update:

nachdem ich die vielen Vorschläge umzusetzen versucht habe, ist mein Artikel nun ein RC2, ein Release Candidate 2 geworden. Wie er nun in der unterteilten Version aussieht, und ob einen dann der Umfang noch immer abschrecken könnte, lässt sich nun ausprobieren.

Liebe Grüße,

Felix Riesterer.

[Christoph]

...allen Übels ;)

Ich habe gerade Mathias' Weblog Eintrag durchgelesen, in dem unter anderem einige Probleme mit JavaScript-Bibliotheken angesprochen werden.

Dein Artikel stellt ja (unter anderem) eine Anleitung dafür dar, wie eine solche erstellt wird, daher dachte ich, dass meine Anmerkung hier eventuell besser als im Weblog-Kommentar aufgehoben sind, da ich gerne explizit auf deine Arbeit Bezug nehmen möchte. Eine Vielzahl dieser 'Framworks' sind in meinen Augen 'over-engineered'. Dein Framework zeigt hier im Kleinen, was in meinen Augen im Großen schief läuft (was jetzt keinesfalls abwertend dir gegenüber klingen soll: ich habe großen Respekt vor der Arbeit, die du offensichtlich in deinen Artikel gesteckt hast; meine Kritik ist vielmehr konzeptioneller Natur).

Ich hatte damals deinen ursprünglichen Thread verfolgt, in dem peterS. ja auch einen alternativen Lösungsansatz vorgestellt hatte. Das hatte mich dazu animiert, eine eigene objektorientierte Lösung zu entwickeln, die ich jetzt als Gegenentwurf zum Framework-Konzept präsentieren möchte.

Das Framework leistet ja vor allem eins: Es stellt eine Fabrik-Methode mit variabler Zahl benannter Parameter zur Erzeugung von Fader-Objekten bereit und kümmert sich um die Interna der Verwaltung mehrerer Fader.

Mein Konzept verzichtet auf ein umschließendes Framework: der Nutzer hantiert direkt mit den Fader-Objekten.

Das funktioniert wie folgt: Anstelle einer Fabrik-Methode wird direkt der Konstruktor aufgerufen. Als Argumente werden nur die tatsächlich benötigten und für jeden Fader verschiedenen Parameter angenommen, bei meinem Fader also die id des Bildelements und ein Array mit den Adressen der weiteren Bilder. Möchte man von den Standardwerten abweichende Werte für die anderen Parameter (z.B. loop, clickable, random, ...), werden diese direkt dem Objekt hinzugefügt (die Standardwerte liegen im Prototyp).

Alles weitere passiert asynchrom im Hintergrund (vorladen der Bilder im Konstruktor, Modifikation des DOM beim ersten 'Schritt' des Faders). Der Nutzer ruft einfach nach initialisieren des Faders dessen start-Methode auf, und das Objekt selbst kümmert sich darum, dass das Bild in ein inline-block-Element gekapselt wird und der Bildwechsel beginnt, sobald alle Bilder geladen sind - es besteht hier keine Notwendigkeit für die weitere Abstraktionsebene 'Framework'!.

Zur Veranschaulichung des Konzepts ein Auszug aus meiner Beispieldatei:

  
var images = ['1.gif', '2.gif', '3.gif', '4.gif'];  
var fader = new Fader('fader', images);  
with(fader) {  
 loop = true;  
 random = true;  
 stepTime = 50;  
 stepCount = 10;  
}  
fader.start();  

Der Code steht in einem script-Block im <head/>. Die start-Methode kann aber grundsätzlich jederzeit (nach Objekt-Initiolisierung) aufgerufen (oder sogar einem Element als Event-Handler zugewiesen) werden.

Christoph

[Felix Riesterer]

Lieber Christoph,

vielen Dank für Deinen Input. Ich muss gestehen, ich verstehe ihn nur zur Hälfte. Dein JavaScript abstrahiert wesentlich stärker (Stichwort "bind"-Funktion), als es das meine tut. Für einen Anfänger (und da zähle ich mich dazu!) ist Dein Ansatz sicherlich noch viel schwerer nachzuvollziehen, als der meine.

Vielleicht möchtest Du - aufbauend auf z.B. meinem Artikel (oder auch nicht) - einen (Ergänzungs-)Artikel schreiben, in dem Du den wesentlichen Unterschied im Ansatz herausarbeitest? Dabei kannst Du das Binden einer an sich unabhängigen Funktion an ein bestehendes Objekt erläutern? Bei Deinem Ansatz bin ich jetzt noch mehr verunsichert, ob Du nun eine Fabrik-Methode benutzt, oder doch einen Konstruktor... STRUPPIIII, wo bist Du, wenn ich Dich brauche?

Liebe Grüße,

Felix Riesterer.

[Timo "God's Boss" Reitz]

vielen Dank für Deinen Input. Ich muss gestehen, ich verstehe ihn nur zur Hälfte. Dein JavaScript abstrahiert wesentlich stärker (Stichwort "bind"-Funktion), als es das meine tut. Für einen Anfänger (und da zähle ich mich dazu!) ist Dein Ansatz sicherlich noch viel schwerer nachzuvollziehen, als der meine.

Mit Erschrecken muss ich feststellen, dass ich Christophs Code leichter verstehe als den des Fader-Frameworks, obwohl Letzterer sogar weniger ist (zumindest das, was ich davon gesehen habe).
Die große Funktion dient dazu, den ganzen Kram, den der Anwender von Fader-Objekten nicht interessiert, zu verstecken. Letztlich ist es simpler Closure, der Kontext ist von außen nicht mehr erreichbar, nur die Fader-Funktion, die als Konstruktor dient, wird zurückgegeben.

Vielleicht möchtest Du - aufbauend auf z.B. meinem Artikel (oder auch nicht) - einen (Ergänzungs-)Artikel schreiben, in dem Du den wesentlichen Unterschied im Ansatz herausarbeitest? Dabei kannst Du das Binden einer an sich unabhängigen Funktion an ein bestehendes Objekt erläutern? Bei Deinem Ansatz bin ich jetzt noch mehr verunsichert, ob Du nun eine Fabrik-Methode benutzt, oder doch einen Konstruktor... STRUPPIIII, wo bist Du, wenn ich Dich brauche?

Das Ergebnis ist ganz sicher ein Konstruktor, neue Fader werden ganz normal mittels new Fader(...); erzeugt.

[Struppi]

vielen Dank für Deinen Input. Ich muss gestehen, ich verstehe ihn nur zur Hälfte. Dein JavaScript abstrahiert wesentlich stärker (Stichwort "bind"-Funktion), als es das meine tut. Für einen Anfänger (und da zähle ich mich dazu!) ist Dein Ansatz sicherlich noch viel schwerer nachzuvollziehen, als der meine.

Hier treffen Welten aufeinander.

Das Abstrahieren (was mir persönlich manchmal sehr sehr schwer fällt) ist eben das A&O in der Objekt orientierten Programmierung. Da du da noch am Anfang stehst, hast du dein Skript quasi "von vorn aufgezäumt" der OO Programmierer macht es i.d.R eher umgekehrt. Erst steht der Entwurf, dann die Muster und dann die Objekte, dann der Code - ein langwieriger und langweiliger Prozess (zumindest für mich), der aber zu einem eleganten Programmablauf führt.

Du erklärst wie du von dem Einen auf das Nächste kommt, was eventuell für Anfänger einfacher ist. Im gegensatz dazu ist Christophs Skript elegant auf das Ergebnis ausgerichtet. Der Anfänger wird aber schwer erkennen was wann wo passiert. Aber das tolle an OOP ist, der Anwender muss das auch gar nicht Wissen, er muss nur wissen, was er an dem Objekt anfassen darf oder soll und dann muss das passieren, was ihm versprochen wird.

Über die ganze Thematik gibt es Bücher, die dicker sind als die Bibel und darin geht es dann nur um die Theorie. Das zeigt wie komplex das Thema ist und wie schierig es sinnvoll zu erklären, dass es jeder versteht. DEN Weg gibt es vermutlich nicht und daher zeigen beide Entwürfe einfach verschiedene Entwicklungstufen. Du darfst dich halt nicht zu sehr auf die lineare Denkweise konzentrieren und müßtest versuchen etwas zu abstrahieren und Christoph müßte versuchen, wenn er das Skript als Erklärungsgrundlage benutzen möchte, den abstrakten Ablauf linear zu erklären, damit auch Anfänger damit zu recht kommen.

Wenn jeder seinen Weg weiter verfolgt, ist das gut und für die Artikelreihe bei selfhtml sicher ein Gewinn.

...Bei Deinem Ansatz bin ich jetzt noch mehr verunsichert, ob Du nun eine Fabrik-Methode benutzt, oder doch einen Konstruktor... STRUPPIIII, wo bist Du, wenn ich Dich brauche?

Schlafen *g*

Im Prinzip wäre es ein Fabrikmethode, aber dazu müsste es ein konkretes Objekt zurückgeben, er gibt aber den Konstruktor zurück und daher kann sie, zumindest in JS, als Konstruktor verwendet werden. Zumal die Funktion gar nicht aufgerufen werden muss, sondern automatisch aufgerufen wird. Was eine Besonderheit in JS ist (oder zumindest von Skriptsprachen ist), es ist eine anonyme Funktion die sich selbst sofort aufruft.

Es gibt noch mehr so Sache in JS. Ich bevorzuge z.b. für meine Framework ansätze sowas:

var meinFramework = new function() {  
/* ... */  
};  

Also einen anonymen Konstruktor, der ein Singleton darstellt. Der grosse Vorteil gegenüber deiner Methode ist, dass du private Variabeln und Funktion deklarieren kannst und in dem Kontrukt immer über this (oder einem Platzhalter) auf das Objekt zugreifen, du musst als nie 'meinFramework' benutzen.

Aber du merkst, bei der Thematik kommt man schnell vom hundersten auf's tausende usw.

Struppi.

[molily]

Hallo,

Ich muss gestehen, ich verstehe ihn nur zur Hälfte. Dein JavaScript abstrahiert wesentlich stärker (Stichwort "bind"-Funktion), als es das meine tut.

Christophs Ansatz ist im Grunde der eines normalen Konstruktors mit privaten und öffentlichen Methoden. Dann hat er noch einen Kniff angewendet, der dafür sorgt, dass die privaten Methoden nur einmal gespeichert werden müssen. Das hat m.W. keinen funktionalen Vorteil, sondern sorgt dafür, dass weniger Speicher belegt wird. Diesen Vorteil erkauft er sich durch den Nachteil, dass er beim Aufruf der privaten Methoden mit call() arbeiten muss, um den Kontext zu korrigieren. (Das ist eine Performance-Optimierung, die mir in dem Kontext egal gewesen wäre - solange ich nicht fünf Millionen Fader pro Dokument habe, dürften die paar Kilobyte Speicher irrelevant sein. Aber vielleicht übersehe ich noch einen weiteren Vorteil zur konventionellen Schreibweise.)

Der entscheidende Unterschied liegt eher darin, das Warten auf das DOM an die Instanz zu delegieren und die Slideshow erst anzufangen, wenn alle Bilder geladen sind.

Für einen Anfänger (und da zähle ich mich dazu!) ist Dein Ansatz sicherlich noch viel schwerer nachzuvollziehen, als der meine.

Das mag sein.

Mathias

[molily]

Hallo,

Habe etwas unterschlagen, will Christoph ja kein Unrecht tun:

Dann hat er noch einen Kniff angewendet, der dafür sorgt, dass die privaten Methoden nur einmal gespeichert werden müssen.

Diesen »Kniff« hat er natürlich auch bei den öffentlichen Eigenschaften angewendet (bei den Methoden hat er es gelassen, siehe Timo), halt über die prototype-Eigenschaft.

Mathias

[Timo "God's Boss" Reitz]

Ich habe mir das Ganze angeschaut, sehr elegant gelöst, aber eine Frage habe ich dennoch:
Was ist der Vorteil der Funktionen, die mittels bind für jedes Fader-Objekt erzeugt werden (die einfach die Argumente an die eigentlichen Funktionen nextStep, start, stop und toggle durchreichen, wobei der Kontext (this) das jeweilige Fader-Objekt ist), gegenüber der Variante, die Funktionen dem Prototypen-Objekt von Fader zuzuweisen?
Statt this.start = bind(start, this); im Konstruktor also Fader.prototype.start=function(...){...}?
Den Rest des Codes wäre m.E. identisch, es geht also nur darum.

[molily]

Hallo,

Was ist der Vorteil der Funktionen, die mittels bind für jedes Fader-Objekt erzeugt werden (...), gegenüber der Variante, die Funktionen dem Prototypen-Objekt von Fader zuzuweisen?

Keiner. Es hat eher den Nachteil, den Christoph bei den privaten Methoden effektiv umgangen hat, nämlich den, dass pro Instanz immer neue Funktionsobjekte erzeugt werden.

Mathias

[molily]

Hallo,

es besteht hier keine Notwendigkeit für die weitere Abstraktionsebene 'Framework'!.

Wenn ich davon ausgehe, dass nicht alle Bilder der Slideshow, sondern nur eines von Anfang an im HTML-Code liegen, kann ich das Vorladen natürlich dem Script überlassen. Ich persönlich finde beide Ansätze nicht so vorteilhaft, für mich hat eine solche Slideshow »unobtrusive« zu sein, bei der alle Bilder schon im Dokument liegen. Wobei eigentlich nicht alle Bilder geladen sein müssen, damit die Slideshow starten kann. Wenn ich das richtig sehe, dann werden in Felix Script die Bilder zwar vorgeladen, es wird aber nicht auf den Erfolg gewartet.

Wenn ich nicht siebenunddreißig Objekte einzeln pollen lassen will, ob das DOM schon verfügbar ist, besteht durchaus die Notwendigkeit, diese Funktionalität zu zentralisieren. Und da bin ich glücklich, dass Felix’ Artikel das Setzen mehrerer load-Handler beschreibt. Gut, man hätte auch das mit deinem Konzept der autonomen Fader-Objekte mit geteilten privaten Methoden lösen können. Andererseits könnte man das Objekt FaderFramework ebenfalls in eine Funktion auflösen. Ich denke, diese beiden Umsetzungen geben sich wenig. Didaktisch gesehen halte ich die Abstraktionsebene eher für verständnisfördernd.

Was an deiner Struktur anders ist, ist natürlich eine Sache, die Felix derzeit ausklammert und die einer eigenen Betrachtung bedarf: Private Methoden, in einer Funktion über dem Konstruktor, sodass sie nicht mit jeder Instanz neu angelegt werden, aber eine Kontextkorrektur nötig haben.

Mathias

[Felix Riesterer]

Lieber Christoph,

nachdem ich dieses Thema nun ein paar Tage habe ruhen lassen, frage ich Dich, ob Du nicht Lust hättest, Deinen Ansatz in einem Feature-Artikel niederzuschreiben, um ihn u.a. mir zu erklären. Gerade in Sachen JavaScript herrscht ein großer Bedarf an Artikeln, denn die JavaScript-Programmierung explodiert zur Zeit wohl gerade - und da Du in Deinem Ansatz eine wesentlich größere Abstraktion leistest, als ich das bei meinem Ansatz tue, wäre das eine prima Ergänzung für die aktuelle Artikelsammlung im Bereich JavaScript.

Was meinst Du dazu?

Liebe Grüße,

Felix Riesterer.