Editor-Entwicklung

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

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

[vento66]

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

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

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

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

Könnte man sicherlich, klingt nicht verkehrt.

[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

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

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

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

[Chris M.]

GA ist drin. wird aber nur angezeigt, wenn man oben den Editor auf "complex" ändert. Könnte man die Auswahl nicht "remanent" speichern? Damit man das nicht jedes mal aktivieren muss?

Ändern geht ganz leicht, in der XSD darf dann dort halt nicht

<xsd:annotation>
   <xsd:appinfo>level:expert</xsd:appinfo>
</xsd:annotation>

stehen. (Bzw. die Attribute die als Complex gelten sollen, brauchen dass dort)

Die größere Frage ist eher:
Welche Attribute sollten Complex sein und welche nicht?

Hier brauchen wir noch einen Konsens und müssen dass dann in der XSD umsetzen.

[swiss]

Seltsam. Ich habe GA nicht drin. Aber gestern kurz vor Mitternacht noch auf die aktuelle Revision aktualisiert

EDIT: Upsss... Ich entschuldige mich und nehme meine Aussage zurück. GA ist drin. wird aber nur angezeigt, wenn man oben den Editor auf "complex" ändert. Könnte man die Auswahl nicht "remanent" speichern? Damit man das nicht jedes mal aktivieren muss?

[alexbeer]

... Bei mir ist das Attribut "ga" vorhanden. Genau genommen das vierte Attribut.

[swiss]

Ich hätte noch einen kleinen Wunsch für den Editor...

Page erlaubt das Attribut "GA". Damit kann man einen ScrollToPage auslösen...

Könnte man dafüe im Editor noch noch ein Eingabefeld erstellen?

[JNK]

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

Gruss,

der Jan