Tach! > > const/let gibt es ja auch noch nicht so lange. Aber laut CanIUse kann das sogar der IE11 in Grundzügen. > > sind Grundzüge ausreichend, dass ein Tutorial-Leser, der das in seinem IE ausprobiert, damit auch nicht scheitert? Ist es wirklich so, das man davon ausgehen muss, dass nur der IE zur Verfügung steht und kein anderer Browser? > > Wenn man es schafft, die Funktionen mit beschreibenden Namen zu versehen, hat man als Leser gleich noch einen Hinweis auf das, was die Funktion tun soll, ohne erst den Code verstehen zu müssen und auch ohne dass da ein Kommentar zur Erläuterung steht. > > Ist das in meinen Beispielen nicht gegeben? Kommentare sind vorhanden. Aber das lindert nur zum Teil, dass die Funktion sehr lang ist. Man muss immer noch verstehen, was da wie zusammenspielt. Bei kleineren Funktionen, die über ihre Parameter und den Rückgabewert eine definierte Schnittstelle zur Außenwelt haben, ansonsten aber eigenständig arbeiten, kann man besser deren Details ausblenden, wenn diese für das Verstehen des großen Ganzen nicht weiter benötigt werden. Das ist quasi wie mit Fachbegriffen. Man lernt diese und was dahintersteht, und kann dann effizient zum eigentlichen Thema kommunizieren. > > Jein, wenn es "ordentlich" sei sollte, müsste man dieses [XY-Problem](https://en.wikipedia.org/wiki/XY_problem) durch Verwendung von <template> vermeiden. > > Aha... OK. Das überblicke ich jetzt gerade nicht, da ich mich noch nicht mit Templates befasst habe. Die Template-Variante würde die Codemenge sehr reduzieren und gleichzeitig mehr Freiheiten geben. Der Dialog definiert nur das Grundgerüst und die grundlegenden Funktionen die zum allgemeinen Handling (Öffnen und Schließen) notwendig sind. Dazu gehört auch, den Inhalt des angegebenen Templates in den Body des Dialogs zu kopieren. Das Template muss nicht einmal in einem <template> sitzen, auch ein verstecktes Div oder ähnlich für ältere Browser geht. Wobei für die ebenfalls das ihnen unbekannte <template> verwendet werden könnte, nur muss das ausgeblendet werden. Wegfallen kann bei diesem Ansatz, ein Konfigurationsobjekt zu erstellen, dessen Syntax man erst noch lernen muss, und selbiges parsen und zu DOM-Elementen umarbeiten zu müssen. Stattdessen erstellt man HTML und es kommt nur ein wenig Code zum Einsatz, der dieses lediglich in den Dialog kopiert. > > Da hast du mich wohl missverstanden. Ich meinte, dass dein Ansatz über das Konfigurationsobjekt nicht nur bei der Gestaltung des Dialoginhalts einschränkt auf das was der dieses Objekt auswertende Code bietet, auch im Editor beim Erstellen des Objekts hat man keinerlei Hilfe durch Autovervollständigung und ähnliche Hilfsmittel. > > Meine Zielgruppe erwartet wohl solche Features in diesem Zusammenhang nicht. Nun, selbst wenn sie keine ausgefeilte IDE zur Verfügung haben, so werden viele von ihnen zumindest einen Editor haben, der grundlegende Syntaxhervorhebung kann. Auch da hilft es, bekanntes HTML erstellen zu können statt ein unbekanntes Objekt. Aber was erwartet die Zielgruppe wirklich? > Und wenn, dann braucht sie mein Tutorial wahrscheinlich nicht mehr. Nun ja, möchtest du zeigen, wie man ein Konfigurationsobjekt liest und wie man DOM-Elemente erstellt? Oder wie man die eingebauten vorgefertigten Dialoge durch eine eigene Variante mit ein paar mehr, jedoch relativ fest vorgegebenen Gestaltungselementen ersetzt? Oder möchtest du zeigen, wie man nicht nur die eingebauten vorgefertigten Dialoge wegbekommt, sondern gleich noch mit recht wenig Code-Aufwand Dialoge mit vollständig individuellen Inhalt bekommen kann? > Mein Ansatz geht auch nicht in die Richtung, dass die Dialoge wirklich alle Möglichkeiten ausreizen, sondern dass sie programmatisch erstellt werden können, um übliche Formulardaten erfassen zu können und so über `confirm` und `prompt` weit hinaus gehen. Wer noch mehr will, geht freilich anders vor! Aber du treibst einen unnötig hohen Aufwand, den man bei gleichzeitig mehr Freiheit deutlich reduzieren kann. > > Man erstellt ein Objekt mit für die IDE unbekannte Struktur. Wenn man die Eigenschaften nicht richtig tippt, gibt es zur Laufzeit kein Ergebnis. Wenn man stattdessen den Dialoginhalt direkt als HTML notieren könnte, wäre die IDE in der Lage, Syntaxprüfungen und Vervollständigung anzubieten. > > Das will der Profi. Der Profi sucht aber nicht mehr unser Tutorial hier zum Lernen auf. Oder doch? Auch der Anfänger mag es einfach. dedlfix.

Tach! > > const/let gibt es ja auch noch nicht so lange. Aber laut CanIUse kann das sogar der IE11 in Grundzügen. > > sind Grundzüge ausreichend, dass ein Tutorial-Leser, der das in seinem IE ausprobiert, damit auch nicht scheitert? Ist es wirklich so, das man davon ausgehen muss, dass nur der IE zur Verfügung steht und kein anderer Browser? > > Wenn man es schafft, die Funktionen mit beschreibenden Namen zu versehen, hat man als Leser gleich noch einen Hinweis auf das, was die Funktion tun soll, ohne erst den Code verstehen zu müssen und auch ohne dass da ein Kommentar zur Erläuterung steht. > > Ist das in meinen Beispielen nicht gegeben? Kommentare sind vorhanden. Aber das lindert nur zum Teil dass die Funktion sehr lang ist. Man muss immer noch verstehen, was da wie zusammenspielt. Bei kleineren Funktionen, die über ihre Parameter und den Rückgabewert eine definierte Schnittstelle zur Außenwelt haben, ansonsten aber eigenständig arbeiten, kann man besser deren Details ausblenden, wenn diese für das Verstehen des großen ganzen nicht weiter benötigt werden. Das ist quasi wie mit Fachbegriffen. Man lernt diese und was dahintersteht, und kann dann effizient zum eigentlichen Thema kommunizieren. > > Jein, wenn es "ordentlich" sei sollte, müsste man dieses [XY-Problem](https://en.wikipedia.org/wiki/XY_problem) durch Verwendung von <template> vermeiden. > > Aha... OK. Das überblicke ich jetzt gerade nicht, da ich mich noch nicht mit Templates befasst habe. Die Template-Variante würde die Codemenge sehr reduzieren und gleichzeitig mehr Freiheiten geben. Der Dialog definiert nur das Grundgerüst und die grundlegenden Funktionen die zum allgemeinen Handling (Öffnen und Schließen) notwendig sind. Dazu gehört auch, den Inhalt des angegebenen Templates in den Body des Dialogs zu kopieren. Das Template muss nicht einmal in einem <template> sitzen, auch ein verstecktes Div oder ähnlich für ältere Browser geht. Wobei für die ebenfalls das ihnen unbekannte <template> verwendet werden könnte, nur muss das ausgeblendet werden. Wegfallen kann bei diesem Ansatz, ein Konfigurationsobjekt zu erstellen, dessen Syntax man erst noch lernen muss, und selbiges Parsen und zu DOM-Elementen umarbeiten zu müssen. Stattdessen erstellt man HTML und es kommt nur ein wenig Code zum Einsatz, der dieses lediglich in den Dialog kopiert. > > Da hast du mich wohl missverstanden. Ich meinte, dass dein Ansatz über das Konfigurationsobjekt nicht nur bei der Gestaltung des Dialoginhalts einschränkt auf das was der dieses Objekt auswertende Code bietet, auch im Editor beim Erstellen des Objekts hat man keinerlei Hilfe durch Autovervollständigung und ähnliche Hilfsmittel. > > Meine Zielgruppe erwartet wohl solche Features in diesem Zusammenhang nicht. Nun, selbst wenn sie keine ausgefeilte IDE zur Verfügung haben, so werden viele von ihnen zumindest einen Editor haben, der grundlegende Syntaxhervorhebung kann. Auch da hilft es, bekanntes HTML erstellen zu können statt ein unbekanntes Objekt. Aber was erwartet die Zielgruppe wirklich? > Und wenn, dann braucht sie mein Tutorial wahrscheinlich nicht mehr. Nun ja, möchtest du zeigen, wie man ein Konfigurationsobjekt liest und wie man DOM-Elemente erstellt? Oder wie man die eingebauten vorgefertigten Dialoge durch eine eigene Variante mit ein paar mehr, jedoch relativ fest vorgegebenen Gestaltungselementen ersetzt? Oder möchtest du zeigen, wie man nicht nur die eingebauten vorgefertigten Dialoge wegbekommt, sondern gleich noch mit recht wenig Code-Aufwand Dialoge mit vollständig individuellen Inhalt bekommen kann? > Mein Ansatz geht auch nicht in die Richtung, dass die Dialoge wirklich alle Möglichkeiten ausreizen, sondern dass sie programmatisch erstellt werden können, um übliche Formulardaten erfassen zu können und so über `confirm` und `prompt` weit hinaus gehen. Wer noch mehr will, geht freilich anders vor! Aber du treibst einen unnötig hohen Aufwand, den man bei gleichzeitig mehr Freiheit deutlich reduzieren kann. > > Man erstellt ein Objekt mit für die IDE unbekannte Struktur. Wenn man die Eigenschaften nicht richtig tippt, gibt es zur Laufzeit kein Ergebnis. Wenn man stattdessen den Dialoginhalt direkt als HTML notieren könnte, wäre die IDE in der Lage, Syntaxprüfungen und Vervollständigung anzubieten. > > Das will der Profi. Der Profi sucht aber nicht mehr unser Tutorial hier zum Lernen auf. Oder doch? Auch der Anfänger mag es einfach. dedlfix.