Difference between revisions of "JKey Player & JKey Editor"

From Biowikifarm Metawiki
Jump to: navigation, search
Line 60: Line 60:
 
::::: wasEdited : false // wird gesetzt, sobald Couplet in Bearbeiten-Modus transformiert wird
 
::::: wasEdited : false // wird gesetzt, sobald Couplet in Bearbeiten-Modus transformiert wird
 
:::: },
 
:::: },
:::: "4n1": { // neue itemID entstanden durch die AddNew action; n ist der separator
+
:::: "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
 
::::: wasOrigin : false, // wird gesetzt, wenn AddNew action ausgeführt wird
::::: wasEdited : true, // wird gesetzt, wenn AddNew action ausgeführt wird
+
::::: wasEdited : true // wird gesetzt, wenn AddNew action ausgeführt wird
::::: originItemID: 4, // Verweis auf uniqueParsedID und dessen obj (wäre in 4n1 enthalten, aber unnötiges extrahieren wird so vermieden)
+
 
:::: },
 
:::: },
 
:::: ...
 
:::: ...

Revision as of 11:08, 2 December 2009

Installation

Todos JKey Player

  • Stresstest

Todos JKey Editor

  • Renummerierung der Couplets beim Bewegen
a) Referenzen der coupletIDs im coupletMemory tauschen
b) für alle itemIDs zugehörig zu einer coupletID (siehe coupletMemory) die unnamed_x mit class jedtCoupletID_jedtParseLeadID suchen und analog zu coupletID den Wechsel anpassen
c) analog alle unnamed_x mit class jedtNextCouplet anpassen (Achtung: für alle couplets, die nicht in den Bearbeiten-Modus überführt wurden, ist das Flag wasEdited 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)
d) die IDs der beiden getauschten Rows mit class edtCouplet sowie table mit class coupletItems anpassen -> letzten Teil ..._coupletX bzw ..._coupletItemsX das X
  • 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 uniqueParsedID)
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