Editor-Entwicklung

[Chris M.]

• Vom UI-Design bin ich noch nicht glücklich (hat sich ja auch noch nicht geändert ) - wenn das ansteht können wir ja nochmal genauer drüber sprechen.

Die Diskussion ist offen Ich bin da ehrlichgesagt auch noch unschlüssig.

Meine Anmerkungen hab ich jetzt mal in den angehängten Screenshot eingebaut.

Außerdem ist mir noch ein Editor-Bug aufgefallen:
Page -> add Child -> <text>-Widget fehlt...

[makki]

Das soll bitte keine "böse Kritik" sein, hinter dem Grundprinzip des Editors, Basis XSD, stehe ich.
Aber teils bin ich bei Chris, das ist böse gesagt einfach noch teils zu umständlich - böse gesagt: vielleicht kann irgendwer mir erkären wie man einem Entwickler erklärt, warum das verquere XML/XSD hilfreich ist, dann bekomme ich das auch vermittelt&verstanden
(ich sehe die Vorteile, aber bis heute ehrlichgesagt mehr Probleme als Nutzen..)

Makki

[Chris M.]

vielleicht kann irgendwer mir erkären wie man einem Entwickler erklärt, warum das verquere XML/XSD hilfreich ist, dann bekomme ich das auch vermittelt&verstanden

Entwickler oder Anwender?

Einem Entwickler muss man das nicht mehr erklären (und wenn, dann eher mal eine gute Fortbildung nahe legen...)

Ein Anwender ist da was anderes. Aber dem erklärt man XML und XSD auch nicht. Das ist genau so irrelevant wie ob sein Laptop von Dell oder Acer ist.
Beim Anwender ist etwas anderes wesentlich entscheidender: Das Verständnis dafür, die Visu Seite[n] zu strukturieren und folglich diese Struktur auch strukturiert abzulegen.
Das geht komfortabel im Editor, denn der kennt alle möglichen und erlaubten Strukturen (nämlich dank der XSD), folglich kann man da nichts falsch machen.
(Und fortgeschrittene, die sich selber zutrauen "<" und ">" in der richtigen Reihenfolge einzugeben, dürfen natürlich gerne direkt an die XML ran. Ist auch nicht sonderlich schwer, geht genau so wie per Hand eine HTML-Seite zu bauen, die ist nämlich auch annähernd XML)

Oder anders: Wir bieten hier Bausteine (wie Lego), die muss der Visu-Ersteller geschickt kombinieren. Und der Editor hilft, in dem der weiß, welche Steine wo und wie zusammenhalten.

[netzkind]

vielleicht kann irgendwer mir erkären wie man einem [Anwender] erklärt, warum das verquere XML/XSD hilfreich ist, dann bekomme ich das auch vermittelt&verstanden

Ganz einfach: garnicht.
Jede Konfiguration von was-auch-immer hat eine feste Struktur und im Idealfall ein Regelwerk dazu, wie die Struktur auszusehen hat. Das ist auch hier der Fall.

Ich wüsste nicht, wieso sich der Anwender dafür interessieren sollte, dass wir XML und ein XSD verwenden. Der Poweruser, gerne. Aber nicht der Anwender. Für den muss es nur funktionieren, und er soll sich nicht von Release zu Release an ein neues Frontend gewöhnen müssen.

Wieso willst du also irgendwem erklären (müssen) warum XML und XSD gewählt wurden?


Dass der Editor noch zu umständlich zu bedienen ist und relativ hässlich obendrein habe ich verstanden, und auf dem Papier besteht bereits ein Plan wie man das ganze wesentlich einfacher und verständlicher gestalten kann.

Dank des Editors wie er jetzt steht gibt es ein relativ umfangreiches Backend um die Konfiguration zu manipulieren. Das was der Anwender als Editor sieht ist nur das Frontend dafür, und ich würde sogar vorschlagen, dessen 2000 Zeilen Code noch mal aufzutrennen nach View und Controller.

Anschließend schwebt mir der Complex-Editor vor, in einer Version wie sie jetzt in etwa schon besteht, und eine vereinfachte Version, die mehr klicki-bunti ist.
Dadurch kann der klicki-bunti näher an der visu geschrieben sein - im schlimmsten Fall hätte man bei broken dependencies immer noch den anderen Editor.

Grüße,
Julian

[netzkind]

Könnte man die Auswahl nicht "remanent" speichern? Damit man das nicht jedes mal aktivieren muss?

Könnte man sicherlich, klingt nicht verkehrt.

[netzkind]

Hi Jan,

Bug: Anlegen eines address-Elements

STR:

1) Switch-Widget anlegen
2) Address-Element mit DPT bestücken
3) in den content eine GA eintragen, die NICHT ins WG importiert wurde

Was passiert: GA wird beim Speichern nicht übernommen
Erwartet: GA wird korrekt gespeichert

Das kann ich bei mir leider nicht reproduzieren.
Basis-Config, direkt in der ersten page einen switch angelegt, in das address als transform "DPT:9.001", in das address-Element "1/2/30" (gibt es bei mir nicht).
Bei save wird sauber gespeichert. Im XML vorhanden und beim Neuladen wird es richtig dargestellt.

[netzkind]

Außerdem ist mir noch ein Editor-Bug aufgefallen:
Page -> add Child -> <text>-Widget fehlt...

Gefixt in SVN 1431, wie auch die restlichen Bugs die vor diesem Post hier im Thread genannt wurden.

Dort ist auch die previewtemp.xml wieder vorhanden, die braucht es später beim release mit den richtigen Zugriffsrechten damit der Editor klappt. File einreichen ohne das ignore zu entfernen ging leider nicht.

[vento66]

Wieso ist der Editor jetzt unter editor.html und nicht mehr unter index.html erreichbar? Ist das auch ein essentielles update?

[netzkind]

AW: Editor-Entwicklung

Wieso ist der Editor jetzt unter editor.html und nicht mehr unter index.html erreichbar? Ist das auch ein essentielles update?

Der Editor ist wie zuvor unter /editor/ oder /editor/?config=faselbla erreichbar.
Directory index macht jetzt nicht mehr die index.html, sondern die index.php, welche für eine Vorab-Validierung zuständig ist.

Wer die editor.html direkt aufruft, braucht nicht nach Support rufen, da fehlerhafte und veraltete Konfigurationen durch die index.php abgefangen werden sollen.

[Chris M.]

Das mit dem Editor habe ich mal als Anlass genommen, den Link zum Editor auf die leere Startseite zu bringen.

Dabei habe ich einen Bug gefunden: Leerzeichen werden gelöscht.
Konkret:

1. Leere Config öffnen (.../visu_svn/)
2. Auf Statusbar schauen ... x - y - z ...
3. Editor öffnen
4. Preview oder gleich auf Safe gehen
5. Leere Config ansehen:
   ... x- y- z ...

Außerdem ein kleiner Useability-Wunsch:
Button um vom Editor wieder zurück auf die Visu-Seite zu gehen. (Z.B. "Öffnen", ggf. mit Check ob dadurch ungespeichertes verloren geht)

[Chris M.]

Weiterer Bug: Opera mag nicht, Meldung:
The configuration appears to be not valid. Please check with 'check_config.php' for details. Error: 'schema is not valid for this configuration, can not find root-level element pages'

(Frage: in wie weit sollen wir Opera unterstützen? Der kann ja nicht mal "user-select:none"...)

[perf]

Bei Android 2.x funktioniert für mich CV nur mit Opera.

/Per

[Chris M.]

Bei Android 2.x funktioniert für mich CV nur mit Opera.

Oben hatte ich Opera am PC gemeint, auf'm Android hab ich Opera noch nicht ausprobiert...

Da bei mit die CV auf dem Android 2.3.6 sowohl im integrierten Browser als auch unter Firefox funktioniert und das auch unterstützte Browser sind, müssen wir dringed klären, warum es bei Dir nicht läuft.

=> Bitte erst mal mit der Demo-Config und forceReload=true, d.h. http://wiregate/visu_svn/?config=demo&forceReload=true testen.

Was passiert?

Wenn das geht (und bei mir geht es), was ist mit den anderen Designs (z.B. per Design-Toggle einfach mal durchklicken)?

Und was ist bei deiner Config, wenn Du forceReload=true anhängst? Was ist, wenn Du dass danach wieder weg lässt?

[perf]

Es funktioniert tatsächlich mit dem demo-config!

Aber mit meinem config funktionert es nicht - nicht einmal mit dem Pure-Design:

http://x.x.x.x/newvisu/visu/?design=...rceReload=true

Das Problem ist (genau wie bei Chrome auf Android 4.x), das das Scrollen blockiert ist.

(Interessanterweise funktionert es mit der Beta-Version von Chrome bei Android 4.x.)

Mein device ist Android 2.2.1.

Mein Config ist angehängt.

/Per

[perf]

Ich habe ein anderes Android 2.x, nämlich 2.3.4 - bei dem gibt es kein Problem.

Leider gibt es für mein 2.2.1 kein Update auf 2.3, und dieser Device ist für mich wichtig - es ist ein Archos Connect 35, der beim Bett steht.

/Per