Editor Weiterentwicklung

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

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

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

Und ein Widget gibt es in genau zwei Varianten (verallgemeinerbar sogar auf eine einzige):

• Container-Widget - kann und wird als Knoten im Addressierungs-Baum auftauchen; aktuell gibt's nur <page> und <group>, in Zukunft könnte man sich evtl. noch ein <popup> vorstellen.
• Widget - ist immer Blatt und das relevante für die meisten Widgets

Die in der Config da drunter existierende XML-Struktur ist nur für die Config. Die ist für mich auch nicht mehr einzeln anklickbar, das ist integraler Bestandteil eines Widgets.


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

[netzkind]

Beispiel "ID_0_10_2":
=> Das zweite Widget auf der Seite, die als zehntes Widget auf der Hauptseite eingebunden wurde.

Was dann ein Widget alles enthält definiert ja die XSD und sind für mich alles Attribute - auch wenn die im XML per Element dargestellt werden müssen um komplexere Datenstrukturen zu erlauben (vgl. Adresse)
Die Ausnahme dieser Regel: Container-Widgets - die dürfen nämlich andere Widgets enthalten. (-> Page und Group)

Dem Editor ist das nicht gleich, da gibt es Knoten, und keine Widgets. Für den Editor sind auch nur Attribute Attribute, und Knoten sind keine Attribute, sondern Knoten. Deshalb kann man das Schema nicht einfach übernehmen, es sei denn es gibt im Adressierungs-Baum keine non-widget-Knoten (address als kleinstes Element wird nie adressiert, da es in der Visu garnicht "anklickbar" ist.

Deshalb die Idee, eine Objektstruktur zu erstellen, die sowohl Visu als auch Editor verstehen, und in der keine Elemente identifiziert werden, sondern bei denen einfach das relevante Element selbst übergeben wird. Also statt "bitte Knoten XY bearbeiten"/"Knoten XY neu laden" ein "bearbeite $this und rufe $this.redraw() auf wenn du fertig bist".
Dazu muss aber die Visu umgestellt werden, dass sich die Widgets nicht mehr am XML bedienen, sondern an einer neuen Abstraktionsschicht die eben den kompletten Baum als Objekte darstellt.

[Chris M.]

Die wichtigste Frage die sich mir stellt, ist, wie identifiziert man einen Knoten. Also wenn die GUI sagt "bearbeite Knoten XY", oder der Editor sagt "Element XY hat sich verändert". Wie wird XY ermittelt, so dass es eindeutig ist? Xpath dürfte ausscheiden, ich glaube nicht, dass wir das geparsed kriegen.

XPath halte ich für deutlichen Overkill.

Um die Widgets zu adressieren gibt es schon jetzt ein Schema (vgl. ID Berechnung für die Subseiten):

• Alle Widgets einer Seite werden bei 0 startend durchnummeriert
• Bei einer (Sub-)Seite wird die ID der Seite genommen und per Underscore getrennt die Widget-Nummer auf dieser Seite angehängt

Beispiel "ID_0_10_2":
=> Das zweite Widget auf der Seite, die als zehntes Widget auf der Hauptseite eingebunden wurde.

Was dann ein Widget alles enthält definiert ja die XSD und sind für mich alles Attribute - auch wenn die im XML per Element dargestellt werden müssen um komplexere Datenstrukturen zu erlauben (vgl. Adresse)
Die Ausnahme dieser Regel: Container-Widgets - die dürfen nämlich andere Widgets enthalten. (-> Page und Group)

Ich hätte noch überlegt, die Visu intern auf JSON umzustellen. Also dass beim Laden der Config alle Knoten geparsed und als Objektstruktur abgelegt werden. Dadurch müssten alle Widgets nicht mehr per jQuery auf das XML zugreifen, sondern per Objektzugriff. Sie könnten außerdem "this" in der Struktur ablegen, so dass man später einfach die Daten im Objekt ändern und ein redraw-Kommando an das Widget senden kann. Außerdem würde es die oben benannte Adressierung lösen, da man nicht adressiert, sondern Referenzen übergibt.
Ich hab noch nicht geschaut, was das für Performance und Speicherbedarf bedeutet, und man würde einen Teil des Editors quasi in die Visu holen (Methoden für redraw, Eigenschaften für editable,...) und es wäre ein major rewrite der Visu notwendig.

Hab ich leider noch nicht ganz verstanden, was Du da wie ändern möchtest.

Als eigentlichen Editor würde ich weiterhin das nutzen was aktuell im SVN ist, da ich in-place-editing nicht sehe (wie sollte das klappen?), sondern aus der Visu heraus Elemente zur Bearbeitung auswählen würde. Themen wie Sortierung, Copy/Paste müsste man dann noch mal separat betrachten, oder erst mal im Editor belassen.

Sehe ich auch so.
Der neue Editor ist vom Konzept her genau richtig. Nur das unmittelbare und optisch identische Feedback fehlt halt.

Das sollte man aber in einem separaten Thread besprechen, also vielleicht kann das einer mit den notwendigen Rechten hier rauslösen und einen Querverweis anlegen.

Done.

[Chris M.]

Ich dachte, wenn Dokument, an sowas wie öffentliches Google Docs Dokument oder Etherpad.

Ist auch ok. Hab mal eines angelegt unter TitanPad: 9JGlZwYeux

[Chris M.]

In diesem Thread habe ich die bzgl. Editor-Weiterentwicklung relevanten Beiträge aus Nächstes Release 0.8.0 - wann? verschoben oder kopiert.

[netzkind]

Format ist mir egal, so lange das Ergebnis passt.
([..] CV-Wiki wäre aber auch nicht verkehrt)

Sehe ich nicht, da das dann nicht mehr frei editierbar ist, und die Schwelle sich zu beteiligen höher, da man sich erst registrieren/freischalten lassen muss.
Ich dachte, wenn Dokument, an sowas wie öffentliches Google Docs Dokument oder Etherpad.

[netzkind]

Na dann lass uns die doch endlich mal festklopfen!

Was brauchst Du denn?
Vermutlich eine Art von Reflection-API, d.h. in der geladenen Visu den Widget-Baum durchiterieren und von jedem Widget die Attribute abfragen.
Außerdem vermutlich ein Live-Ändern der Attribute und ein ändern des Baums, oder?

Die wichtigste Frage die sich mir stellt, ist, wie identifiziert man einen Knoten. Also wenn die GUI sagt "bearbeite Knoten XY", oder der Editor sagt "Element XY hat sich verändert". Wie wird XY ermittelt, so dass es eindeutig ist? Xpath dürfte ausscheiden, ich glaube nicht, dass wir das geparsed kriegen. Jedem Element

Ich hätte noch überlegt, die Visu intern auf JSON umzustellen. Also dass beim Laden der Config alle Knoten geparsed und als Objektstruktur abgelegt werden. Dadurch müssten alle Widgets nicht mehr per jQuery auf das XML zugreifen, sondern per Objektzugriff. Sie könnten außerdem "this" in der Struktur ablegen, so dass man später einfach die Daten im Objekt ändern und ein redraw-Kommando an das Widget senden kann. Außerdem würde es die oben benannte Adressierung lösen, da man nicht adressiert, sondern Referenzen übergibt.
Ich hab noch nicht geschaut, was das für Performance und Speicherbedarf bedeutet, und man würde einen Teil des Editors quasi in die Visu holen (Methoden für redraw, Eigenschaften für editable,...) und es wäre ein major rewrite der Visu notwendig.

Als eigentlichen Editor würde ich weiterhin das nutzen was aktuell im SVN ist, da ich in-place-editing nicht sehe (wie sollte das klappen?), sondern aus der Visu heraus Elemente zur Bearbeitung auswählen würde. Themen wie Sortierung, Copy/Paste müsste man dann noch mal separat betrachten, oder erst mal im Editor belassen.

Das sollte man aber in einem separaten Thread besprechen, also vielleicht kann das einer mit den notwendigen Rechten hier rauslösen und einen Querverweis anlegen.

[Chris M.]

Wir könnten ja mal einen Wünsch-dir-was Thread zum Editor aufmachen, oder alternativ ein öffentliches Dokument zur allgemeinen Bearbeitung, um mal alle "Anforderungen" zu sammeln die ein Editor in unser aller Augen erfüllen soll. Dann hat man immerhin mal einen Überblick.

Format ist mir egal, so lange das Ergebnis passt.
(Thread hat sicher die geringste Einstiegshürde, halte ich aber zu unübersichtlich. Würde aber die Diskussion gut ermöglichen.
Evtl. ist ein Forum-Lexikon-Artikel dann die beste Lösung - die man auch gut mit Thread kombinieren kann.
Feature Request Tracker dürfte das offensichtlichste und von mir präferierte sein; CV-Wiki wäre aber auch nicht verkehrt)

und wer will, kann ernstgemeinte bounties (Prämien) zu einzelnen Feature Requests ausschreiben. Damit bekommt man vielleicht schneller was man selber will, ohne warten zu müssen dass anderer Leute Wünsche umgesetzt werden.

Klar das steht immer offen.
Wobei ich spontan nicht wüsste wie man hier die beste "Geschäfts-Anbahnung" organisiert.

Mich würde so ein WYSIWYG Editor auch wieder reizen,

Der optimale Editor wäre eine Vereinigung des WYSIWYG (vgl. 0.6) mit dem "externen Editor" (vgl. 0.8-pre)!

Je nach Editier-Aufgabe ist das eine oder das andere Konzept das effizientere.

aber ich gehe sowas nicht an, solange mir die Interaktion zwischen Editor und Visu nicht so klar ist, dass sie noch in 24 Monaten läuft.

Na dann lass uns die doch endlich mal festklopfen!

Was brauchst Du denn?
Vermutlich eine Art von Reflection-API, d.h. in der geladenen Visu den Widget-Baum durchiterieren und von jedem Widget die Attribute abfragen.
Außerdem vermutlich ein Live-Ändern der Attribute und ein ändern des Baums, oder?

Wie soll das API laufen?
Ursprünglich hatte ich an reines JS gedacht - aber vermutlich ist es besser die Visu per IFrame einzubinden, denn dann kann man bewusst geringe IFrame-Größen einstellen um andere Auflösungen (z.B. Touch PC in der Wand) im Editor zu simulieren.
Dann dürfte https://developer.mozilla.org/en/DOM/window.postMessage wohl eine gute Basis für die API darstellen (nach Can I use... Support tables for HTML5, CSS3, etc quasi überall implementiert)

[netzkind]

Aber man müsste dann auch einenn Leistungskatalog zusammenstellen, in dem steht, was der neue Editor können muss. Und wie er aussehen sollte. Sonnst weiss man ja nicht, was man am Ende für sein Geld bekommt.

Wir könnten ja mal einen Wünsch-dir-was Thread zum Editor aufmachen, oder alternativ ein öffentliches Dokument zur allgemeinen Bearbeitung, um mal alle "Anforderungen" zu sammeln die ein Editor in unser aller Augen erfüllen soll. Dann hat man immerhin mal einen Überblick.
Alternativ kann man auch über Feature Requests steuern was zu tun ist, und wer will, kann ernstgemeinte bounties (Prämien) zu einzelnen Feature Requests ausschreiben. Damit bekommt man vielleicht schneller was man selber will, ohne warten zu müssen dass anderer Leute Wünsche umgesetzt werden.

Mich würde so ein WYSIWYG Editor auch wieder reizen, aber ich gehe sowas nicht an, solange mir die Interaktion zwischen Editor und Visu nicht so klar ist, dass sie noch in 24 Monaten läuft.

Grüße,
Julian

[Chris M.]

Was wären denn die Anforderungen an die Person und wie groß wäre das Zubrot, also mit was könnte man denn Werben ? ^^

Vermutlich hängen die genauen Vorlieben davon ab, wer letztendlich die Bezahlung übernimmt.

Ich würde (ohne dass ich mich um die Bezahlung kümmern würde!) als Grundanforderung sehen:

• Selbstständiges Arbeiten
• Auch etwas Nehmerverhalten im Sinne des Boxsportes

Fachlich wäre sicher noch geschickt (je mehr um so besser, ein interessierter der sich einarbeitet ist mir aber immer lieber als ein unmotivierter, der schon was kann...):

• JavaScript
• HTML
• CSS
• Ggf. etwas PHP
• Ggf. etwas ästhetisches Empfinden
• Linux oder Unix Grundkenntnisse

Grundsätzlich könnte man sich hier auch eine Arbeit im Rahmen vom Google Summer of Code vorstellen - außer dass ich nicht weiß, wie man das einsteuert und wir für dieses Jahr schon zu spät sind...


Fachliche Betreuung sollte über das Forum und eMails leicht organisierbar sein. Da sehe ich keine Probleme.

[swiss]

Hmm... Man könnte eine art Spendenkonto einrichten auf dass jeder der das Projekt Editor unterstützen möchte etwas überweisen könnte. Dann könnte man auf Wunsch auch anonym spenden.

Da mir die CometVisu und einen benutzerfreundlichen Editor sehr am Herzen liegt, wäre ich mit 50 dabei. Aber man müsste dann auch einen Leistungskatalog zusammenstellen, in dem steht, was der neue Editor können muss. Und wie er aussehen sollte. Sonnst weiss man ja nicht, was man am Ende für sein Geld bekommt.

[Gringo885]

Nachtrag:

Evtl. kenn auch jemand einen Studenten (oder gar einen fitten Schüler...) der sich hier in den Semesterferien ein Zubrot verdienen möchte und gleichzeitig ein gewisses Skill-Set aufbauen oder nachweisen möchte (macht sich bei zukünftigen Jobs oder gar Arbeitgebern immer gut!).

Dann dürften wir sicher deutlich günstiger zu einer passenden Lösung kommen

Was wären denn die Anforderungen an die Person und wie groß wäre das Zubrot, also mit was könnte man denn Werben ? ^^

Ich kann sonst einfach mal nen paar Informatiker an unserer TU fragen bzw. das mal in das Studentenforum eintragen. Wenn Anforderungen / Auftrag und Lohn stehen könnte sich da vlt wer finden. Sind ja im mom Klauuren bzw. Semesterferien

Gruß Gringo

[henfri]

Hallo,

was für ein Release auch noch nötig ist -s.o.- ist eine vernünftige Installationsanleitung.

Zum Editor:
Mir ist das momentan noch zu viel geklicke auf +.
Kann man das nicht auf das Wesentliche reduzieren?

Ich denke, es sollten einfach alle Parameter sofort sichtbar sein.
Elemente, die nur einen Parameter haben, sollten keinen Unterpunkt haben, sondern der Unterpunkt sollte direkt angezeigt werden:
Statt:
Label
+Text
Wohnzimmer

Label Text: Wohnzimmer

Ein live-Preview des aktuellen Element wäre aber schon super, so wie du das skizziert hast.

Was ich auch nicht verstehe ist, warum man nicht direkt darin editieren kann.
Also klick auf den Text und man kann den Text ändern. Rechtsklick auf einen Slider und man kann die GAs ändern.

Zur Smartvisu/Smarthome:
Ich bin nicht ganz sicher, ob ich dich bzgl. Backend richtig verstehe. Was nett ist an der Kombination sh/sv ist die Autogeneration von Konfigurationen. Das würde ein CV-Backend für sh.py ja nicht adressieren.
Und die Tatsache, dass ich statt Gruppenadressen direkt die sh.py Items (also z.B. eg.wohnzimmer.licht.dimmwert) adressieren kann. Würde das mit einem CV-Backend gehen?

Gruß,
Hendrik