Editor Weiterentwicklung

[MGK]

ich habe dann auch mal ein paar Anwender-Gedanken in das TitanPad eingetragen...

Michael

[Chris M.]

Das ist ein Nebeneffekt. Das Social Debugging scheint zu funktionieren

Schau mal ob Commit 1853 jetzt besser ist (und keine anderen Nebenwirkungen hat...)

[Peter]

Editor Weiterentwicklung

Hallo
so sieht das vor und nach dem Update aus.

[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?

[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)

[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.]

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...

[henfri]

Habe gerade meine Gedanken im titanpad eingetragen.

Gruß,
Hendrik

[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?

[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.

[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.

[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

[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

[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?

[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.