JKey Player & JKey Editor

From Biowikifarm Metawiki
Revision as of 11:39, 2 December 2009 by Stephan Opitz (Talk | contribs)

Jump to: navigation, search

Installation

Todos JKey Player

  • Stresstest

Todos JKey Editor

  • Renummerierung der Couplets beim Bewegen
a) Referenzen der zu den coupletIDs gehörenden objs mit den itemIDs im coupletMemory tauschen
b) transformiert: für alle itemIDs zugehörig zu einer coupletID (siehe coupletMemory) die ...unnamed_x (die mit class jedtCoupletID_jedtParseLeadID) suchen und analog zu coupletID den Wechsel anpassen
c) transformiert: analog alle ...unnamed_x (die mit class jedtNextCouplet), sprich "Next Lead" anpassen
d) transformiert: alle ...unnames_xc (die mit class jedtCoupletBacklink) anpassen
e) nicht transformiert: dt-nodeid suchen und Inhalt in der cell direkt ändern; nach leadalt suchen und schaun ob "(\d+)" und anpassen
f) nicht transformiert: "span.leadon a" links anpassen
g) natürlich auch "alle anderen Couplets" betrachten und ändern, die auf die "bewegten" verweisen ("Next Lead" || "span.leadon a")
h) Achtung: für alle Couplets, die nicht in den Bearbeiten-Modus überführt wurden, ist das Flag wasEdited natürlich noch nicht gesetzt worden im coupletMemory - also entwedern neues Flag mit neuem Wert einführen im itemID obj und dann beim Serialisieren beachten oder direkt im jedtParsedPageData in den uniqueParsedID objs ändern; bei "alle anderen Couplets" auch Änderungen merken
i) die IDs der beiden getauschten Rows mit class edtCouplet sowie table mit class coupletItems anpassen -> letzten Teil ..._coupletX bzw ..._coupletItemsX das X
  • Renummerierung aller Couplets beim Speichern
  • Stresstest

Aufbau jedtParsedPageData und coupletMemory

  • jedtParsedPageData enthält die geparste Struktur einer WikiSeite
  • für jeden Schlüssel, wenn er bearbeitet wird, werden zusätzliche Felder (wasEdited, domRef, coupletMemory) innerhalb des zugehörigen "Key Start"-Templates eingefügt, durch die der Bearbeiten-Vorgang dokumentiert wird (weitere Änderungen an der Struktur werden nicht vorgenommen)
  • Bsp. einer geparsten Struktur:
"0":{ // beliebiges Template, was keine Felder besitzt ("0" entspricht einer "unique parsed ID")
type: "{{",
closingType: "}}",
startIndex: 0,
endIndex: 23,
name: "Documentation/subpage",
whitespaceAtEnd:""
},
"1": { // Lücke mit textuellem Inhalt
type: "contentGap",
startIndex: 25,
endIndex: 918,
},
"2": { // öffnendes Key-Template (zusätzlich durch den Editor hinzugefügt: wasEdited, domRef, coupletMemory); jeder Schlüssel erwartet ein schliessendes Key-Template
type: "{{",
closingType: "}}",
startIndex: 918,
endIndex: 1717,
name: "Key Start",
whitespaceAtEnd: "\n"
wasEdited: true,
domRef: div#wild.decisiontree, // direkte Referenz zum obj im DOM
fields: {
"0": {
closingType: "|",
startIndex: 930,
endIndex: 943,
name: "id",
content: "wild",
whitespaceAtStart: " ",
whitespaceAtEnd: "\n ",
isLastField: false,
isUnnamedField: false,
},
...
},
coupletMemory: { // enthält Struktur des Schlüssels (coupletIDs + ihre "decisions"); ist nur im Key Start und hier wird bei jeder Änderung des Nutzers der Inhalt angepasst
"1": { // coupletID extrahiert aus den Feldern innerhalb der uniqueParsedID
"4": { // itemID -> zugehörigen "decisions" zur coupletID; "4" ist der Verweis auf die uniqueParsedID
wasOrigin : true, // default gesetzt bei original geparstem "decisons"
wasEdited : false // wird gesetzt, sobald Couplet in Bearbeiten-Modus transformiert wird
},
"4n1": { // neue itemID entstanden durch die AddNew action; n ist der separator; Zahl davor ist Verweis auf uniqueParsedID und dessen obj
wasOrigin : false, // wird gesetzt, wenn AddNew action ausgeführt wird
wasEdited : true // wird gesetzt, wenn AddNew action ausgeführt wird
},
...
},
...
}
},
"3": {
type: "contentGap",
startIndex: 1719,
endIndex: 1720,
},
"4": { // Template für eine "decision"; itemIDs innerhalb des coupletMemorys zeigen hierauf
type: "{{",
closingType: "}}",
startIndex: 1720,
endIndex: 2670,
name:"Lead",
whitespaceAtEnd:" "
fields: {
"0": {
closingType: "|",
startIndex: 1727,
endIndex: 1731,
name: 1,
content: "1",
whitespaceAtStart: " ",
whitespaceAtEnd: " ",
isLastField: false,
isUnnamedField: true,
}
...
}
} ...
"tplNames": { // enthält alle aufgetretenen Template-Namen für das dynamische Nachladen von HtmlEditorTemplate's
Lead: 32, // 32 entspricht Anzahl, wie oft das Template während des Parsevorgangs aufgetreten ist
...
},

Parser Definition

  • Hürde: Leerzeichen/Returns/Tab \n\r\t nach "{{" müssen weg: "{{ Key Start" = "{{Key Start" HIER können sie dauerhaft weg, aber NICHT in den Parameter values...
  • Hürde: nach {{ bis erstem "|" (= Template name):
a) trimmen (mit returns),
b) underscores gegen blank normalisieren (so rum!) "{{Key_Start" = "{{Key Start"
Ergebnis Templatename bekannt, evtl. Key Start gefunden.
Hinweis: theoretisch kann Templatename selbst durch Template erzeugt werden also "{{XTemplate:REST|..." wobei REST ein Y liefert und der Template name dann wäre. (DIES UNTERSTÜTZEN WIR NICHT!)
  • Hürde: nächste pipe finden, die nicht in [[]] oder {{}} geschachtelt ist:
also 1="5''" und 2 ="[[Blütenkrone| {{Color|val=purpurn|lang=de}}]] oder rosa" {{Lead | 5''| [[Blütenkrone| {{Color|val=purpurn|lang=de}}]] oder rosa | 4 }}
Geschachtelte Tpls sollen übersprungen werden!
Hinweis: theoretisch könne öffnende oder schließende doppelklammern aus Template-Ergebnissen kommen. DIES UNTERSTÜTZEN WIR NICHT!
  • DABEI bereits prüfen, ob vor der ersten "[[", "{{", oder "|" ein Gleichheitszeichen kommt. Wenn ja dann named parameter, sonst unnamed.
Hinweis: theoretisch kann der Parameter name selbst durch Template erzeugt werden also "{{XY|par{{Number}}=123|..." wobei Number ein 2 liefert und der name dann par2 wäre. (DIES UNTERSTÜTZEN WIR NICHT!)
Hinweis: Letzten beiden Punkte sind eine gemeinsame Schleife, die zwei Dinge prüft.
  • sowohl parameter name als auch parameter value werden auf beiden Seiten whitespace-trimmed (aber im parameter value, sind returns und blanks signifikant)
  • & tags und dessen childs ignorieren = überspringen