Re: [DSA Manager] Element-Klassen (Entwurf 1)
Status: Planning
Brought to you by:
alexnofftz
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-14 15:02:03
|
Hi Oliver! >> DSA Manager >> > > Besser: DSA. Wir wollen nicht unser Programm beschreiben, sondern > das DSA-Regelsystem. Vielleicht wird diese Struktur ja auch mal > außerhalb des Managers benutzt. Oder wir bleiben bei der "Wurzel" aller Bezeichnungen und nennen das Ding root ;-) >> | |--> Eigenschaften >> | | |--> Nicht steigerbar (AT, PA, MR, ST, SO...) >> | | \--> Steigerbar > > Besser anders. Man weiß nie, was plötzlich doch steigerbar sein > wird. Dann kann man die Klassenbezeichnung ja überschreiben. > Und auf einige Sachen kann man z.B. Boni kaufen. Ja, aber so etwas sehe ich eher als Vorteil an. LE kann man doppelt aufführen, einmal die Basis-LE unter "Meta-Eigenschaften" und dann die gekauften LeP als steigerbare Eigenschaft, das kommt auch der Regel sehr nahe. >>Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig >>Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen >>leicht lösen ;-) > > Inwiefern genau? Nun, schlechte Eigenschaften gelten als Nachteil, haben aber in gegesatz zu diesen einen Wert und sind "steigerbar", also genau wie Eigenschaften. >>Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert >>ist (wie unter HTML auch): > > NMTOKEN kommt nicht in Frage. NMTOKEN darf Dinge wie ":", "-", etc. enthalten. > Das gibt Operatorenkonflikte, außer die ID's kommen immer in Quotes. Was willst du mit : und - in den Namen? Die kann man ja explizit ausschießen. >> <property id="MU" class="EigGut"> >> ... >> </property> >> > [...] > >> ... >> <advantage id="NatJähzorn" class="Nachteil EigSchlecht"> >> > > Das geht mir zu weit. Wenn man nachher für alles das gleiche > Tag hat, verliert man alle Vorteile, die XML bietet. Ein Tag für jede *Oberklasse* von Objekten, also eine für Eigenschaften, eine für Vor- und Nachteile, eine für Talente und Zauber, also alles, was sich nur minimal unterscheidet. > Abgesehen > davon sind Eigenschaften und Vorteile z.B. wirklich nicht das > gleiche. Basiseigenschaften haben Eigenschaftswerte, machen > aber keine action's, ... Das sind verschiedene Elemente mit > verschiedenen Attributen und verschiedenen möglichen Kindern. Richtig, eine Eigenschaft mit <action>s habe ich Meta-Eigenschaft genannt, kann man ja dann auch als <meta-property> definieren. >>Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile >>ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss, >> > > Du hast schon recht, da advantage und disadvantage Tag genau die selbe > Definition haben werden, könnte man sie zusammenlegen. > Ich würd's dennoch lassen, denn man wird Vor- und Nachteile oft > getrennt handeln, und dann im Programm aufgrund der ersten > Buchstaben der ID's zu trennen ist nicht wirklich elegant. Nein, das geht anhand der Klasse. Die ersten drei Buchstaben sollen nur klar machen, auf was die ID sich bezieht und von vornerein einige Namenskollisionen ausschließen. Macht man in großen Klassenbibliotheken ja auch so. >><property id="MU" class="EigGut"> > ... >></property> >><property id="NatJähzorn" class="Nachteil EigSchlecht"> > > Man kann nich fast alles in einen Topf werfen. Nicht alles, aber denke mal streng nach, worin sich die guten und die schlechten Eigenschaften wirklich unterscheiden, außer der logischen Einordnung unter "Nachteile" und den abgewandelten Steigerungsregeln (zu denen ich schon was geschrieben hatte) eigentlich überhaupt nicht. > Auch die Mehrfachvererbung löst nicht nur Probleme, sondern > schafft ganz eigene. XML ist geeignet für eine direkte > Hierarchie, nicht für Mehrfachvererbung. Die Mehrfachvererbung bezieht sich ja nicht auf das XML, sondern darauf, wie der DSA Manager die darin enthaltenen Daten auswertet. Wenn ich z.B. alle Tags heraussuche, deren Klasse "Nachteil" enthält, erhalte ich alle Nachteile, auch die schlechten Eigenschaften. Will ich eine Liste aller Talente haben, suche ich nach der Klasse "Talente". Will ich nur die Kampfzauber haben, suche ich nach der entsprechenden Klasse etc. >>Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal >>festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran >>gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie >>normale Eigenschaften definieren. > > Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so > häufig vor, das was vererbt wird (Die Attribute ein Beispiel, > aber so viel anderes gibts nicht). Ich denke, es besser, in > den paar Fällen die Dinge mehrfach anzugeben. Es kommt vor bei: - Eigenschaften - Meta-Eigenschaften - Vorteilen, Nachteilen - Talenten (erben aus der Talentgruppe) - Talent-Spezialisierungen - Rüstungs- und Waffenkategorien Soll ich weitermachen? ;-) >>Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur >>eingeordnet sind, brauche ich mich für Ableitungen oder den >>Charakterbögen nur darauf zu beziehen: >> >> <property id="MyJähzorn" ref="NatJähzorn"> >> <value base="7"/> >> </property> >> > > value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT Wert > bei Talenten). Verschiedene Wert-Typen sollten verschiedene Tags haben. > Und man braucht auch hier nicht zwangsläufig Vererbung. Es ist eh mehr > eine Instanziierung. Die AT/PA-Werte sind ein Sonderfall, ansonsten reicht <value> wirklich. Warum unterschiedliche Tags für Dinge definieren, die im Grunde dasselbe meinen? >>Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal >>schauen, was Xerces aus solchen Angaben macht... > > Bitte nicht alle Cutting-Edge Features von Xerces ausnutzen, wir > werden Xerces für C++ vermutlich nicht benutzen. Bestimmt nicht, aber wenn ihr den C++-Xerces verwendet, stellen wir sicher, dass die XML-Datei gleich ausgewertet und gespeichert werden. Vielleicht macht eine andere Bibliothek einige Dinge minimal anders, und dann sind die Dateien nach ein paar Mal laden, steigen und speichern nicht mehr kompatibel... Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |