nicht angemeldet
Struktir Javascript-Referenz
[latex]Mae govannen![/latex]
Momentan beginnt jemand, die Javascript-Objektreferenz mehr oder weniger 1:1 ins Wiki zu übertragen. Da ich gerade diesen Bereich eigentlich immer schon (in mehreren Beziehungen) sehr suboptimal aufgeteilt und beschrieben fand, würde ich es begrüßen, wenn wir uns _vorher_ ein paar Gedanken machen, wie gerade dieser Bereich verbessert werden könnte. Ansonsten würde es bedeuten, daß alle Arbeit, die jetzt gemacht wird, unter Umständen doppelt gemacht oder komplett umgebaut werden muß.
Ich sprach es im "ist SelftHTML tot"-Thread bereits einmal an, daß ich es z.B. schön finden würde, wenn einheitlich für jede Methode die Parameterübergabe und Rückgabe und für Eigenschaften der Rückgabe-Typ
nach einem Schema ähnlich dem, wie es z.B. auf php.net (Beispiel) verwendet wird (vielleicht etwas gestraffter, die einzelnen Parameter nur kurz anreißen um einen schnellen Überblick zu haben und im folgenden text genauer beschreiben), aufgebaut würde.
Also:
Syntaxübersicht
Liste der Parameter mit Beschreibung
Beschreibung eventueller Rückgabewerte
Hinweise & text & beispiel(e)
Ein entsprechendes Template dazu?
Was soll mit Methoden/Eigenschaften geschehen, die deprecated sind? Weiterhin unter dem entsprechenden Objekt aufzählen (und z.B. mit entsprechender Hintergrundfarbe hinterlegen oder lieber einen eigenen Bereich "veraltete methoden/Eigenschaften"
Weiteres im Laufe des Tages.
Ihr könnt ja schon mal losdiskutieren :)
Cü,
Kai
--
Deutsches Liedgut international:
In early rope to mountain we pull
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
Deutsches Liedgut international:
In early rope to mountain we pull
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
Hallo Kai,
Momentan beginnt jemand, die Javascript-Objektreferenz mehr oder weniger 1:1 ins Wiki zu übertragen.
vom Grundsatz her ist es erfreulich, dass sich was tut. Das sollte man nicht verhindern und auch nicht ausbremsen.
Da ich gerade diesen Bereich eigentlich immer schon (in mehreren Beziehungen) sehr suboptimal aufgeteilt und beschrieben fand,
Ich stimme Dir zu.
Ansonsten würde es bedeuten, daß alle Arbeit, die jetzt gemacht wird, unter Umständen doppelt gemacht oder komplett umgebaut werden muß.
Es gibt Schlimmeres. Ganz bestimmt wird es nicht die einzige derartige Baustelle sein. Hier sehe ich jedoch den Vorteil des Wikis: Es passiert etwas und man kann es sehen. Man kann es verbessern. Schön, dann machen wir's, wenn es nötig ist.
wenn einheitlich für jede Methode die Parameterübergabe und Rückgabe und für Eigenschaften der Rückgabe-Typ
nach einem Schema ähnlich dem, wie es z.B. auf php.net (Beispiel) verwendet wird (vielleicht etwas gestraffter, die einzelnen Parameter nur kurz anreißen um einen schnellen Überblick zu haben und im folgenden text genauer beschreiben), aufgebaut würde.
das halte ich für eine gute Idee.
Also:
Syntaxübersicht
Liste der Parameter mit Beschreibung
Beschreibung eventueller Rückgabewerte
Hinweise & text & beispiel(e)Ein entsprechendes Template dazu?
Solange keines da ist, wie wäre es mit der Methode, einfach mit gutem Beispiel und vorhandenen Möglichkeiten vorangehen?
Was soll mit Methoden/Eigenschaften geschehen, die deprecated sind? Weiterhin unter dem entsprechenden Objekt aufzählen (und z.B. mit entsprechender Hintergrundfarbe hinterlegen oder lieber einen eigenen Bereich "veraltete methoden/Eigenschaften"
was sich bewähren wird. Lassen wir uns überraschen.
Freundliche Grüße
Vinzenz
-
[latex]Mae govannen![/latex]
Ansonsten würde es bedeuten, daß alle Arbeit, die jetzt gemacht wird, unter Umständen doppelt gemacht oder komplett umgebaut werden muß.
Es gibt Schlimmeres. Ganz bestimmt wird es nicht die einzige derartige Baustelle sein. Hier sehe ich jedoch den Vorteil des Wikis: Es passiert etwas und man kann es sehen. Man kann es verbessern. Schön, dann machen wir's, wenn es nötig ist.
Ich halte - und deshalb eröffnete ich auch diesen Thread - es für wesentlich mehr Arbeit, die bereits ins Wiki übertragene Doku nachträglich wieder (evtl. komplett) umzuwerfen, zumal, wenn es so kommt, die ganze Arbeit der Person, die das jetzt überträgt, merh oder weniger hinfällig werden könnte. Gut, bei einem Wiki muß man damit ohnehin sicher rechnen, aber noch ist relativ wenig übertragen und man kann noch schadenminimierend einwirken.
Zum Beispiel wäre abzuklären, ob die Doku wie bisher aufgebaut wird, d.h. eine Seite pro Objekt und auf dieser Seite alle Eigenschaften und Methoden oder ob man es dahingehend abändert, daß jede Eigenschaft/Methode eine eigene Seite bekommt und die Objektseite php.net-mäßig als eine Übersicht mit Kurzbeschreibung ausgelegt wird
URL-mäßig würde sich nicht sehr viel ändern:
[...]/Objektreferenz/window/location#href
vs
[...]/Objektreferenz/window/location/href
Also:
Syntaxübersicht
Liste der Parameter mit Beschreibung
Beschreibung eventueller Rückgabewerte
Hinweise & text & beispiel(e)Ein entsprechendes Template dazu?
Solange keines da ist, wie wäre es mit der Methode, einfach mit gutem Beispiel und vorhandenen Möglichkeiten vorangehen?
Genau da liegt das Problem. Zum einen liegt der Wiki-Start in einer -für mich- äußerst ungünstigen Zeit, zum Anderen will ich durch diese Diskussion hier vermeiden, daß an [latex]X[/latex] Stellen im Wiki mit [latex]X[/latex] unterschiedlichen Konzepten zu bauen begonnen wird, die man dann nachträglich wieder aneinander angleichen muß.
Eine Doku sollte in sich jedenfalls einigermaßen konsistent aufgebaut sein, daher halte ich es für sinnvoll, vorher darüber zu reden. Kostet schließlich nichts ;)
Cü,
Kai
--
Deutsches Liedgut international:
In early rope to mountain we pull
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Hallo Kai,
vorweg: JavaScript ist (momentan) nicht meine Baustelle; dies sind nur mal meine allgemeinen Gedanken zum Thema.
[Ich will] durch diese Diskussion hier vermeiden, daß an [latex]X[/latex] Stellen im Wiki mit [latex]X[/latex] unterschiedlichen Konzepten zu bauen begonnen wird, die man dann nachträglich wieder aneinander angleichen muß.
Ich kann das absolut verstehen und finde es auch sehr freundlich, dass du nicht später die Arbeit von anderen Leuten löschen willst.
Andererseits: Ich persönlich glaube, man kann sich vorher noch so viele Gedanken über die "beste" Struktur machen, aber welcher Ansatz wirklich der sinnvollste ist, merkt man erst, wenn man's bis zu einem gewissen Grad ausprobiert hat. Egal, wie "offensichtlich" es anfangs auch erscheinen mag, dass der eine Ansatz eher "schlecht" und der andere ganz klar "besser" sei.
Ich rechne auch damit, dass vieles, was ich schreibe, später als unbrauchbar erkannt und eingestampft wird.Man muss als Autor damit fertigwerden, dass andere den eigenen Kram löschen, und man muss ebenso den Mut aufbringen, fehlgeschlagene Experimente von anderen Autoren umzuarbeiten oder ganz zu löschen. (Meine Meinung.)
Viele Grüße
Mathias-
[latex]Mae govannen![/latex]
Andererseits: Ich persönlich glaube, man kann sich vorher noch so viele Gedanken über die "beste" Struktur machen, aber welcher Ansatz wirklich der sinnvollste ist, merkt man erst, wenn man's bis zu einem gewissen Grad ausprobiert hat. Egal, wie "offensichtlich" es anfangs auch erscheinen mag, dass der eine Ansatz eher "schlecht" und der andere ganz klar "besser" sei.
Das ist richtig. Man kann allerdings eventuell frühzeitig(er) eine Tendenz zu einem oder gegen einen bestimmten Ansatz erkennen bzw. mögliche Probleme oder Argumente die man nicht bedacht hat.
Man muss als Autor damit fertigwerden, dass andere den eigenen Kram löschen, und man muss ebenso den Mut aufbringen, fehlgeschlagene Experimente von anderen Autoren umzuarbeiten oder ganz zu löschen. (Meine Meinung.)
Mit dem zweitem Punkt hätte _ich_ ehrlich gesagt schon gewisse Probleme. Bin also nicht uneingeschränkt geeignet als Autor. Hm.
Cü,
Kai
--
Deutsches Liedgut international:
In early rope to mountain we pull
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Hallo Kai!
Mit dem zweitem Punkt hätte _ich_ ehrlich gesagt schon gewisse Probleme. Bin also nicht uneingeschränkt geeignet als Autor. Hm.
Autsch! Da hab ich mich ja wieder doof ausgedrückt. Mit "Da muss man als Autor den Mut aufbringen, ...", wollte ich nichts über die Voraussetzungen zur Eignung als Autor aussagen.
Also sag ich es mal andersrum: Man *braucht* sich da eigentlich keine Sorgen drum zu machen. Ich sehe kein Problem darin, wenn mehrere Autoren parallel das gleiche Thema beackern und verschiedene Ansätze ausprobieren. (Kann ja auch jeder auf seinen eigenen Benutzerseiten machen.) Ich sehe das auch nicht als Ressourcenverschwendung, sondern als den nötigen Wildwuchs in einer kreativen Phase.
Am Schluss vergleicht man dann, was am besten ist, oder lässt im Forum darüber diskutieren, und das Beste nimmt man dann halt. Man muss als Autor ja auch nicht die Drecksarbeit des Löschens persönlich machen; das überlässt man einfach dem Redaktionsteam. ;-)
Viele Grüße
Mathias
-
-
-
-
-
Ich würde, um die Übersichtlichkeit der Referenz zu erhöhen, so etwas wie ein Cheat Sheet verwenden (also eine Auflistung der Objekte, Methoden und Eigenschaften, die einerseits auf Detailbeschreibungen verlinken und andererseits einen nützlichen Tooltip haben).
Gruß, LX
--
RFC 1925, Satz 6a: Es ist immer möglich, einen weiteren Umweg einzufügen.
RFC 1925, Satz 11a: Siehe Regel 6a
-
Hallo LX,
Ich würde, um die Übersichtlichkeit der Referenz zu erhöhen, so etwas wie ein Cheat Sheet verwenden (also eine Auflistung der Objekte, Methoden und Eigenschaften, die einerseits auf Detailbeschreibungen verlinken und andererseits einen nützlichen Tooltip haben).
Ich zweifle zwar nicht die Nützlichkeit einer solchen Darstellung an, _auf den ersten Blick_ finde ich jedoch *keine* für *mich* hilfreiche Information. Deswegen halte ich das nicht für eine gute Idee.
Ich möchte mehr Fleisch. Von Anfang an. Nicht weiterklicken, nicht erst Tooltip gucken. Kais Vorschlag, sich an der PHP-Doku zu orientieren halte ich für geeigneter und vor allem auch einsteigerfreundlicher.
Freundliche Grüße
Vinzenz
-
Hi, Vinzenz!
Für Anfänger und Fortgeschrittene ist die PHP-Doku mit Sicherheit ein sehr positives Beispiel, an dem man sich orientieren kann. Ich habe aber festgestellt, dass solche Cheat Sheets bei der täglichen Arbeit die Fortgeschrittenen und Profis durchaus unterstützen kann. Natürlich ist das keine eigenständige Dokumentation, aber in vielen Situationen eine schnellere Möglichkeit der Gedächtnisstütze.
Ich werde auf jeden Fall früher oder später so etwas für JavaScript bauen. Ob wir es ins Wiki integrieren oder überhaupt nutzen, ist eine ganz andere Frage.
Gruß, LX
--
RFC 1925, Satz 2: Egal, wie fest man schiebt, ganz gleich, wie hoch die Priorität ist, man kann die Lichtgeschwindigkeit nicht erhöhen.-
Hallo LX,
Ich habe aber festgestellt, dass solche Cheat Sheets bei der täglichen Arbeit die Fortgeschrittenen und Profis durchaus unterstützen kann. Natürlich ist das keine eigenständige Dokumentation, aber in vielen Situationen eine schnellere Möglichkeit der Gedächtnisstütze.
deswegen schrieb ich ja:
"Ich zweifle [...] nicht die Nützlichkeit einer solchen Darstellung an [...]"
Ich werde auf jeden Fall früher oder später so etwas für JavaScript bauen. Ob wir es ins Wiki integrieren oder überhaupt nutzen, ist eine ganz andere Frage.
ich meine: sicher, gern. Warum nicht einen Abschnitt: "Cheat Sheets"?
Freundliche Grüße
Vinzenz
-
-
-
-
Hallo,
die Gelegenheit möchte ich hier nutzen, um ein generelles Anliegen für die Struktur der Javascript-Referenz loszuwerden.
Momentan beginnt jemand, die Javascript-Objektreferenz mehr oder weniger 1:1 ins Wiki zu übertragen.
Sieht man sich die Javascript-Referenz 1.5 an, gliedert diese sich (ohne den mozilla-eigenen Kram) in folgende Punkte:
1. Global Objects 1. Standard global objects (By type) 2. Basic Data types 3. Static 4. Errors 5. Standard global objects (Alphabetical) 2. Global Properties 3. Global Functions 4. Functions and function scope 5. Statements 6. Operators 7. Comments 8. E4X (extension)Meiner Meinung nach macht es Sinn, sich an den Standard mit der Gliederung anzupassen, und nicht in die spärliche Aufteilung SELFHTMLs zurück zu fallen.
Gruß aus Berlin!
eddi-
Hallo Eddie,
Meiner Meinung nach macht es Sinn, sich an den Standard mit der Gliederung anzupassen, und nicht in die spärliche Aufteilung SELFHTMLs zurück zu fallen.
ich befürworte Deinen Vorschlag.
Freundliche Grüße
Vinzenz
-