JKey Player & JKey Editor
From Biowikifarm Metawiki
Revision as of 11:22, 2 December 2009 by Stephan Opitz (Talk | contribs)
Contents
Installation
- Javascript-Files: MediaWiki:JKey.js & MediaWiki:JKeyEditor.js
- Editor-Tpl-Files: MediaWiki:Lead/HtmlEditorTemplate
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) 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 "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,
- },
- ...
- "0": {
- },
- 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
- },
- ...
- "4": { // itemID -> zugehörigen "decisions" zur coupletID; "4" ist der Verweis auf die uniqueParsedID
- },
- ...
- "1": { // coupletID extrahiert aus den Feldern innerhalb der uniqueParsedID
- }
- },
- "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,
- }
- ...
- "0": {
- }
- } ...
- "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
