Difference between revisions of "JKey Player & JKey Editor"
From Biowikifarm Metawiki
| Line 27: | Line 27: | ||
* "jkey-nocontrols" - keine Player Controls anbieten | * "jkey-nocontrols" - keine Player Controls anbieten | ||
| − | = Infos JKey Editor == | + | == Infos JKey Editor == |
* jedtParsedPageData enthält die geparste Struktur einer WikiSeite | * 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) | * 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) | ||
Revision as of 12:47, 2 December 2009
Contents
Installation
- Javascript-Files: MediaWiki:JKey.js & MediaWiki:JKeyEditor.js
- Editor-Tpl-Files: MediaWiki:Lead/HtmlEditorTemplate
Todos JKey Player
- neue Bilder für historyActiveOn & historyActiveOff
- Stresstest
Todos JKey Editor
- neues Bild für edtIconActionEdit
- 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 ...unnamed_x (die mit class jedtNextCouplet), sprich "Next Lead" anpassen, wenn nötig
- d) transformiert: alle ...unnames_xc (die mit class jedtCoupletBacklink) anpassen, wenn nötig
- e) nicht transformiert: dt-nodeid suchen und Inhalt in der cell direkt ändern; nach leadalt suchen und schaun ob "(\d+)" und anpassen, wenn nötig
- f) nicht transformiert: "span.leadon a" links anpassen, wenn nötig
- 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 (letzteres würde verlangen, das die felder dann einzeln serialisiert werden); 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
Infos JKey Player
- wenn in "Key Start" ein field: "flags" existiert, kann mit den Werten "jkey-autostart" und "jkey-nocontrols" zusätzliche Funktionalität gesteuert werden
- "jkey-autostart" - Schlüssel automatisch in den interaktiven Modus wechseln
- "jkey-nocontrols" - keine Player Controls anbieten
Infos JKey Editor
- 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
