Editor Weiterentwicklung

[netzkind]

Für mich gibt es im Addressierungs-Baum nur Widgets, sonst nichts. (Zumindest was unter dem obersten <page /> liegt, <meta /> ist natürlich die Ausnahme der Regel - aber das ist im WYSIWYG auch nicht greifbar).

[...]
Welche "non-widget-Knote" könntest Du Dir denn vorstellen?

Mir fallen spontan keine ein, aber das bedeutet nicht, dass sich das nicht ändern wird. Stichwort Navigation. Mir ist der Ansatz zu sehr auf "aktuell ist es so und so" ausgerichtet, womit es meiner initialen Anforderung "muss auch in 24 Monaten noch laufen" nicht gerecht zu werden scheint.

Solange der Editor die config selbst lädt und sich per Adressierung seinen Knoten suchen muss, müssen wir auch die Config-Struktur als Adressierungs-Grundlage verwenden, und nicht den Visu-Gedanken der Widgets, um nicht das gleiche Problemszenario wie beim alten Editor zu erhalten (dass die Entwicklung der coolen Dinge wie Widgets der Entwicklung der uncoolen Dinge wie dem Editor davonläuft).

[Chris M.]

Unter Revision 1839 habe ich mal ein Mockup einer Reflection API eingecheckt.

Dazu einfach die Seite index_external_editor_test.html?config=demo&forceR eload=true öffnen.
Im Terminal sind nun erst mal zwei neue Befehle definiert:

• talkToVisu('list')
  Listet die komplette Visu-Struktur; Rückgabe ist ein entsprechend verschachteltes Object.
• talkToVisu('read',<Pfad>) - z.B. talkToVisu('read','id_0_34_9')
  Liest das Widget mit dem entsprechenden Pfad aus und gibt ein Object mit allen Parametern zurück

Hinweis: die Implementierung hat bekannte Fehler (z.B. werden zu simple Widgets wie <line> beim Zählen ignoriert und werden folglich alles durcheinander bringen; außerdem gibt 'read' eben noch nicht die Attribute zurück, statt dessen nur ein Demo-Object)

Wenn eine solche API hilfreich ist, würde ich die funktionsfähig machen. Aber nur dann - denn ich müsste ein paar Stellen aufräumen, den das zwar fürchterlich gut tut, aber halt auch erst mal ein Risiko tragen... (Wie gut, dass wir noch keinen Feature Freeze haben )

Mir fallen spontan keine ein, aber das bedeutet nicht, dass sich das nicht ändern wird. Stichwort Navigation. Mir ist der Ansatz zu sehr auf "aktuell ist es so und so" ausgerichtet, womit es meiner initialen Anforderung "muss auch in 24 Monaten noch laufen" nicht gerecht zu werden scheint.

Solange der Editor die config selbst lädt und sich per Adressierung seinen Knoten suchen muss, müssen wir auch die Config-Struktur als Adressierungs-Grundlage verwenden, und nicht den Visu-Gedanken der Widgets, um nicht das gleiche Problemszenario wie beim alten Editor zu erhalten (dass die Entwicklung der coolen Dinge wie Widgets der Entwicklung der uncoolen Dinge wie dem Editor davonläuft).

Der alte Editor war IMHO zu sehr mit der damals akutellen Config-Struktur verheiratet. Nachteile sind bekannt.
Der neue Editor ist nun das Gegenteil, der ist extrem generisch - aber eben auch kaum Wissen über die Visu. Aufgrund der Historie verständlich, aber eben auch nicht optimal.

Optimal ist eine Mischung, so generisch wie möglich, so konkret wie nötig. (OK, ich zahl schon freiwillig in's Phrasen-Schwein ein...)

Konkret müssen wir uns einfach ein paar grundlegende Regeln überlegen, denen die Visu folgt und die der Editor folglich als gesetzt annehmen darf.

Und für mich ist das, dass ein Widget die kleinste adressierbare Einheit ist (nämlich per Pfad. Und der folgt immer /^id(_[0-9]+)+$/).
Es mag als Container-Widget noch weitere Widgets enthalten - aber selbst ist es als atomar anzusehen.

Die Navigation mag gerne auf andere Seiten o.ä. referenzieren - aber auch da ist's erst mal ein Widget (eindeutig per Pfad adressierbar) das auf andere Wdgets oder Seiten (auch wieder eindeutig per Pfad adressierbar) verweist.

[netzkind]

Mir schwebte im Kopf eher etwas in der Art:
Die Visu ganz normal anzeigen. Beim Umschalten in den Edit-Modus bekommt jedes geeignete Widget einigen Edit-Button verpasst. Klick darauf, und dieses Element wird im Editor geladen. Save/Preview und man kommt zurück mit geänderten Widget.

Wie der Edit-Button aussieht/platziert ist, entscheidet jedes Design selbst. Ich würde zwecks edit einfach dem Body die Klasse edit geben, und die Widgets bekommen dann per before/after im CSS den Button. Alternativ per durchiterieren und jedem Widget Bescheid geben. Den Button-klick abzufangen macht man dann im JS, idealerweise jedes Widget alleine. Das meldet sich dann beim Editor und sagt "dieses Element zum Bearbeiten laden".

Dadurch ergeben sich gewisse Grundanforderungen die jedes Widget im Code erfüllen muss. Dazu gehören "Edit-Button anzeigen", "klick auf Button abfangen/Editor laden" und "geändertes Widget erzeugen und das bestehende ersetzen". Das kann man entweder über eine Art Klassenvererbung machen, oder durch Nutzung generischer Handler. Jedem Widget steht es frei, keinen Edit-Button anzubieten, es muss aber ggf. iterieren sofern es Kinder haben kann.
Solange man dann diese Regeln beachtet, würde die Interaktion zwischen Editor und Visu nach meiner Einschätzung lange halten.

[netzkind]

Die Navigation mag gerne auf andere Seiten o.ä. referenzieren - aber auch da ist's erst mal ein Widget (eindeutig per Pfad adressierbar) das auf andere Wdgets oder Seiten (auch wieder eindeutig per Pfad adressierbar) verweist.

Ich meinte die Navigation als Widget innerhalb der Visu. Ist die nicht Teil von meta?

[Chris M.]

Unter Revision 1839 habe ich mal ein Mockup einer Reflection API eingecheckt.

Die Start-Seite hatte ich vergessen einzuchecken
Egal, ist jetzt da. Außerdem die oben noch beschriebenen offensichtlichen Probleme behoben - was aber auch heißt, dass ich evtl. eine Regression eingebaut haben könnte...

Mir schwebte im Kopf eher etwas in der Art:
Die Visu ganz normal anzeigen. Beim Umschalten in den Edit-Modus bekommt jedes geeignete Widget einigen Edit-Button verpasst.

Auf den TreeView würde ich ungerne verzichten - es gibt Aufgaben, da ist der deutlich effektiver als nur WYSIWYG.
Optimal ist natürlich wenn man beides hat und beides verlinkt ist. D.h. ein Klick in den TreeView selektiert das Widget - und umgedreht führt die Auswahl eines Widgets in der Visu zur Selektion im TreeView

Klick darauf, und dieses Element wird im Editor geladen. Save/Preview und man kommt zurück mit geänderten Widget.

Ja, aber in beide Richtungen gleichzeitig.

Wie der Edit-Button aussieht/platziert ist, entscheidet jedes Design selbst. Ich würde zwecks edit einfach dem Body die Klasse edit geben, und die Widgets bekommen dann per before/after im CSS den Button. Alternativ per durchiterieren und jedem Widget Bescheid geben. Den Button-klick abzufangen macht man dann im JS, idealerweise jedes Widget alleine. Das meldet sich dann beim Editor und sagt "dieses Element zum Bearbeiten laden".

Ja, dass kommt meiner Vorstellung auch in etwa nahen.

Dadurch ergeben sich gewisse Grundanforderungen die jedes Widget im Code erfüllen muss. Dazu gehören "Edit-Button anzeigen", "klick auf Button abfangen/Editor laden" und "geändertes Widget erzeugen und das bestehende ersetzen". Das kann man entweder über eine Art Klassenvererbung machen, oder durch Nutzung generischer Handler.

Das gehört für mich in's _common.js und kommt damit automatisch zu jedem Widget dazu. Kostet dann auch annähernd keine Resourcen dank Referenzen.

Jedem Widget steht es frei, keinen Edit-Button anzubieten, es muss aber ggf. iterieren sofern es Kinder haben kann.

Hm, so lieberal wäre ich nicht. Jedes Widget sollte selektierbar sein. Evtl. zwangsweise über den div.widget_container - denn (inzwischen ) ist wirklich jedes Widget in einem .widget_container eingesperrt.

Solange man dann diese Regeln beachtet, würde die Interaktion zwischen Editor und Visu nach meiner Einschätzung lange halten.

Das ist das Ziel. Einfach das minimal notwendige Set an Regeln aufstellen, an die sich Visu und Editor halten müssen. Dann sollte sich jeder in jede Richtung weiterentwickeln können ohne den anderen abzuhängen.

Ich meinte die Navigation als Widget innerhalb der Visu. Ist die nicht Teil von meta?

Hm, verstehe ich jetzt nicht.

Meta ist eigentlich nur für (in sich unsichtbare...) Definitionen. (Die Statusbar ist die Ausnahme dieser Regel. Die hat aber auch keine Widgets)
Daher ist Meta auch aus Prinzip nicht per WYSIWYG anfassbar.

Die Navbars sind dagegen in den <page> Elementen definiert, da die so Kontext abhängig aufgebaut werden können. Daher dürfte dort eine 100% WYSIWYG eine Herausforderung sein. Aber schon existierende Einträge können natürlich wunderbar zum Selektieren dienen

[MicHau]

Außerdem die oben noch beschriebenen offensichtlichen Probleme behoben - was aber auch heißt, dass ich evtl. eine Regression eingebaut haben könnte...

Ja, es gibt eine.
Warum wird bei Line

forceWidth: '100%'

gemacht? Im Navbar kann man die Linie vertikal verwenden. Das führt nun natürlich zu einem hässlichen Umbruchdes Navbar über mehrere Zeilen.
Sehen kann man das in der visu_config_metal.xml

[netzkind]

AW: Editor Weiterentwicklung

Auch wenn die Diskussion hier inzwischen ins komplett technische abgedriftet ist, interessiert vor allem auch die Meinung der User, was die Anforderungen an den Editor sind. Chris hatte dazu ein Dokument verlinkt das jeder ergänzen/bearbeiten kann und darf.

[Chris M.]

Ja, es gibt eine.
Warum wird bei Line

forceWidth: '100%'

gemacht?

Weil durch den (nun verpflichtenden) widget_container die Line sonst nur eine halbe Seite breit gewesen wäre...

Im Navbar kann man die Linie vertikal verwenden. Das führt nun natürlich zu einem hässlichen Umbruchdes Navbar über mehrere Zeilen.

OK, dann schau ich mal, was ich da reparieren kann.

Auch wenn die Diskussion hier inzwischen ins komplett technische abgedriftet ist, interessiert vor allem auch die Meinung der User, was die Anforderungen an den Editor sind. Chris hatte dazu ein Dokument verlinkt das jeder ergänzen/bearbeiten kann und darf.

Da darf ich gerne nochmal darauf verweisen: TitanPad: 9JGlZwYeux

Wer noch kein Etherpad genutzt hat: das ist extrem simpel! Einfach reinschreiben (am besten sich auch noch rechts oben einen Namen geben, damit die Editierungen nachvollziehbar sind).

Und wenn man viel geschrieben hat, kann man auch auf Speichern drücken, dann wird das als Version abgelegt.

[MicHau]

AW: Editor Weiterentwicklung

Weil durch den (nun verpflichtenden) widget_container die Line sonst nur eine halbe Seite breit gewesen wäre...

OK, dann schau ich mal, was ich da reparieren kann.

Kann man der Line nicht ein Layout-Element spendieren?

[henfri]

Habe gerade meine Gedanken im titanpad eingetragen.

Gruß,
Hendrik

[Chris M.]

Kann man der Line nicht ein Layout-Element spendieren?

Ja, das wäre eine der möglichen Lösungen.

Ich möchte da eh noch mehr bei den verschiedenen Widgets vereinheitlichen...

[tht]

Da ich momentan noch dabei bin die ganzen Bussysteme und das Haus dazu fertig zu stellen, kann ich mich leider nicht aktiv an der Entwicklung beteiligen, aber ich werde die Tage mal versuchen "mein Idealbild" in Form von Scribbles und etwas Text zu definieren.

Die Anforderungen werden wohl für den Moment zu hoch sein, aber vllt. bleiben ja ein paar Ideen übrig .

[Chris M.]

So, <line> sollte so gehen wie immer gewollt - allerdings mit dem Vor- bzw. Nachteil dass man jetzt per <layout> ein colspan setzen kann.

=> Linien im Metal in der Top-Nachbar brauchen nun ein <layout colspan="0"/>
=> Alle anderen Linien brauchen nun ein <layout colspan="12"/>
=> Alle bestehenden Configs müssen angepasst werden

(Wenn man das nicht macht, geht die Linie nur über die Hälfte, da per Default ein colspan="6" gesetzt ist)

[MicHau]

AW: Editor Weiterentwicklung

Hi Chris,

deine letzten Änderungen führen dazu, dass nun auch die Labels von den Stylings betroffen sind.
Ist das beabsichtigt oder ungewollter Nebeneffekt?

[Peter]

Editor Weiterentwicklung

Hallo
so sieht das vor und nach dem Update aus.