Vorlage Diskussion:Nebenkrater
Umstellen der Vorlage
BearbeitenDiese Form der Tabellengenerierung (Kopfvorlage, Zeilenvorlage, Fußvorlage) ist störanfällig. Besser ist es, die Tabelle in einer Vorlage zusammenzufassen. Dazu eignet sich eine Werteübergabe mittels zusammengesetzter Parameterwerte, also solche mit einem Schrägstrich als Trennung. Ein Aufruf sähe dann z.B beim Krater Buch so aus:
{{Nebenkrater |Name=Buch |A=-41/17.6/19 |B=-37.8/17.0/6 |C=-37.3/17.2/28 |D=-39.6/16.5/7 |E=-39.0/16.5/6 }}
Wenn außer Großbuchstaben auch noch andere Labels vorkommen, dann würde das Ganze so aussehen:
{{Nebenkrater |Name=Buch |Label1/41/17.6/19 |Label2/37.8/17.0/6 |Label3/37.3/17.2/28 | ... }}
Also Standardparameter und das Label als erster Teil des Werts. Das ist viel einfacher als die aufgeteilte Vorlage mit viel Redundanz. Die Auswertung der Parameter erfolgt mit Vorlage:ParmPart. ÅñŧóñŜûŝî (Ð) 20:00, 17. Jan. 2012 (CET)
- Was ist der Gewinn dabei? Wieso störanfällig? Es werden bei weitem auch nicht immer alle Buchstaben vergeben und auch nicht immer in Folge (manchmal nur H und W etc.). Soll das, was jetzt in Vorlage:Nebenkrater ist, n-mal wiederholt werden? Wo gibt es ein Beispiel? Insgesamt siehst Du mich wenig überzeugt. --LeastCommonAncestor 20:17, 17. Jan. 2012 (CET)
- Es geht um eine Einbindung für die ganze Tabelle.
- Vorteile sind:
- Die übliche Zuordnung einer derartigen Tabelle zu nur einer Vorlage. Das ist auch für andere verständlich.
- Es ist nicht erforderlich, dass drei Vorlagen immer zusammenpassen müssen.
- kompakte Schreibweise, der Name muss z.B. nur einmal geschrieben werden und die Werte werden nur durch "/" und "|" getrennt. Schneller geht es nicht.
- Stören würden spätere Einschübe zwischen den Einbindungen, Änderungen bei den Leerzeichen, etc.
- Bei meinem 1. Modell würden fehlende Buchstaben auch nicht auftauchen, beim 2. Vorschlag können die Bezeichner sogar beliebig sein.
- Für ein Beispiel müsste ich diese Vorlage komplett umschreiben, was aber quasi vollendete Tatsachen wären. Du kannst es dir aber auch so vorstellen: Die Tabelle sieht aber anschließend genauso aus wie jetzt, die Einbindung wie oben dargestelllt.
- Bei bisher ca. 10 Einbindungen ist das in wenigen Minuten umgestellt. ÅñŧóñŜûŝî (Ð) 20:34, 17. Jan. 2012 (CET)
- Beispiel:
{{Nebenkrater |1=A/-41/17.6/19 |2=B/-37.8/17.0/6 |3=C/-37.3/17.2/28 |4=D/-39.6/16.5/7 |5=E/-39.0/16.5/6 }}
würde
Buchstabe | Position | Durchmesser | Link |
---|---|---|---|
B | 37° 48′ 0″ S, 17° 0′ 0″ O | 6 | |
C | 37° 18′ 0″ S, 17° 12′ 0″ O | 28 | |
D | 39° 36′ 0″ S, 16° 30′ 0″ O | 7 | |
E | 39° 0′ 0″ S, 16° 30′ 0″ O | 6 |
ergeben. Die Formatierung der Zellen habe ich auf die Schnelle weggelassen und den Namen benötigen wir eigentlich auch nicht. Der Quelltext steht auf Benutzer:Antonsusi/Nebenkrater. ÅñŧóñŜûŝî (Ð) 20:53, 17. Jan. 2012 (CET)
- Also wirklich, da klaffen unsere Vorstellungen von "einfach" weit auseinander. Man müsste also für über 20 Nebenkrater das ganze über 20mal wiederholen, bei jeder Änderung das über 20mal ändern. Sorry. Ich denke, ich mach dass in der vielleicht etwas redundanten, aber wesentlich durchschaubareren, besser wartbaren und flexibleren Art. Inzwischen gibt es auch einen benannten Parameter NeuerName. Mit Deinem Ansatz hätte man sich schnell in die Ecke gemalt. --LeastCommonAncestor 21:04, 17. Jan. 2012 (CET)
- Wieso musst du da bei 20 Nebenkratern 20 mal wiederholen, was du vorher sowieso mit 20 Einbindungen von "Nebenkrater" 20 mal wiederholt hast ? Was meinst du mit "bei jeder Änderung das über 20mal ändern" ? Da sehe ich nichts, was man 20 mal ändern müsste. Wir können auch benannte Paramter nehmen. Das sähe dann einfach so aus:
{{Nebenkrater |Name=Buch |Krater1=A/-41/17.6/19 |Krater2=B/-37.8/17.0/6 |Krater3=C/-37.3/17.2/28 |Krater4=D/-39.6/16.5/7 |Krater5=E/-39.0/16.5/6 |.... |Krater20=a/b/c/d }}
Mit einem Eintrag vom Typ
|KraterN=C/<NeuerName>
kann man auch Sonderfälle berücksichtigen. ÅñŧóñŜûŝî (Ð) 21:19, 17. Jan. 2012 (CET)
- Im Quelltext der Vorlage wird wiederholt (in Deinem Beispiel Benutzer:Antonsusi/Nebenkrater 6-mal, beim Krater Abulfeda wären das ein paar mehr, sieh hier). Der benannte Parameter repräsentiert einen Sonderfall in einer Zeile, siehe Euler (Mondkrater). --LeastCommonAncestor 21:32, 17. Jan. 2012 (CET)
- Ach das meinst du. Natürlich wird im Quelltext wiederholt. So oft, wie maximal Nebenkrater gelistet werden sollen. Jede Wiederholung wird eine Tabellenzeile, aber nur, wenn der Parameter Text enthält, also genutzt wird. Wenn wir 30 derartige Zeilen in die Vorlage schreiben, dann dürfte das für alle Artikel ausreichen, und wenn nicht, dann erweitern wir auf 40. Entscheidend ist, wie viele Parameter im Artikel mit einem Text belegt werden, denn nur die werden ja angezeigt. Du must die Vorlage ja nur einmal schreiben. In jedem externen Editor mit C&P eine Arbeit von wenigen Minuten. Komplexere Zeilen sind mit Untervorlagen leicht realisierbar. ÅñŧóñŜûŝî (Ð) 21:43, 17. Jan. 2012 (CET)
- Komplexere Zeilen gibt es schon und eine entsprechende Vorlage auch. Ich kann absolut keinen Gewinn dabei erkennen, der die Umständlichkeit aufwiegt. Außerdem könnte man so keine Schrägstriche in den Koordinaten verwenden (also zB "6/17/22.3/N"). Auch in der Kategorie:Vorlage:Tabellenformatierung finde ich eine Reihe von Beispielen für meinen Ansatz und kein einziges Beispiel für Deinen Ansatz. --LeastCommonAncestor 22:04, 17. Jan. 2012 (CET)
- Ach das meinst du. Natürlich wird im Quelltext wiederholt. So oft, wie maximal Nebenkrater gelistet werden sollen. Jede Wiederholung wird eine Tabellenzeile, aber nur, wenn der Parameter Text enthält, also genutzt wird. Wenn wir 30 derartige Zeilen in die Vorlage schreiben, dann dürfte das für alle Artikel ausreichen, und wenn nicht, dann erweitern wir auf 40. Entscheidend ist, wie viele Parameter im Artikel mit einem Text belegt werden, denn nur die werden ja angezeigt. Du must die Vorlage ja nur einmal schreiben. In jedem externen Editor mit C&P eine Arbeit von wenigen Minuten. Komplexere Zeilen sind mit Untervorlagen leicht realisierbar. ÅñŧóñŜûŝî (Ð) 21:43, 17. Jan. 2012 (CET)