Editor-Entwicklung

[netzkind]

Wiso kann man den Editor nicht einfach anweisen alle Kindelemente die ein minOccurs =1 haben automatisch zu erstellen? Dann wäre alles was ohnehin gebraucht wird um Valide zu sein schon vorhanden und muss nur noch vom User ausgefüllt werden.

In dem letzten Beispiel von mir zu RSS hat nur das Choice-Element ein minOccurs=1.
Der Editor weiß also nur "entweder label oder layout müsste auftauchen", aber er weiß nicht, welches von beiden.

Gäbe man nun label ein minOccurs=1 wäre das immer noch keine Lösung: das XML ist immer noch valide wenn keines vorhanden ist, da der Validator sagen kann "es ist einmal '0 layout' vorhanden, also alles gut".

Geben wir jetzt dem choice noch ein minoccurs=2, dann würde das immer noch nix nutzen, weil wir dann immer noch haben "es ist zweimal '0 layout' vorhanden".

Eine Lösung (in diesem Fall) könnte ein xsd:all anstelle des xsd:choice sein (achtung, versteht der Editor noch nicht, da es noch nicht nötig war).
Wir können aber nicht alle choice durch ein all ersetzen, weil all sagt "0 oder 1 mal". In XSD 1.1 darf man das "0 oder 1 mal" tatsächlich überschreiben, aber ich hab noch nicht rausgefunden, wie man das XSD als 1.1 markiert, oder dem Validator sagt, dass er es als 1.1 interpretieren soll ...

Insgesamt ist XSD halt doch extrem nerdig...

[alexbeer]

Hm - bin überfragt. Verstehe aber noch nicht warum,

<rss src="https://knx-user-forum.de/external.php?type=RSS2" header="true">       </rss>

das valide ist - ohne Definition von label ohne layout.

Bei einer solchen XSD Definition wäre es ja schön, wenn der Editor die XSD:Choice Passage auswerten könnte und die definierte Bedingung prüft und dann eine Fehlermeldung à la:

Im Typ $complexType muss von den Elementen $element[1], ..$element[n] mindestens $minOccurs Einträge hinzugefügt werden!

Das ganze dann möglichst so dynamisch, dass es auf alle Fälle anwendbar wäre...

P.S:
Offensichtlich habe ich meine XSD manuell angepasst - mit welchem SVN Befehl zwinge ich nur die XSD zu überschreiben?

svn revert -R .;svn up

ist ja für alles - oder lösche ich einfach die xsd und mit nem

svn up

ist alles wieder OK?

[swiss]

Hier doch nochmal zu meiner Frage, da mir durch deinen Beitrag die Funktionsweise der XSD etwas klarer geworden ist...

Wiso kann man den Editor nicht einfach anweisen alle Kindelemente die ein minOccurs =1 haben automatisch zu erstellen? Dann wäre alles was ohnehin gebraucht wird um Valide zu sein schon vorhanden und muss nur noch vom User ausgefüllt werden.

[netzkind]

Hi Alex,

In der XSD ist folgendes definiert:

<xsd:complexType name="rss" >
    <xsd:choice maxOccurs="unbounded" minOccurs="1">
        <xsd:element name="label" type="xsd:string" maxOccurs="1" />
    </xsd:choice>

Demnach müsste ja genau ein Label-Element gefordert sein! (s. XML Schema choice Element)

Bei mir steht da

  <xsd:complexType name="rss">
    <xsd:choice maxOccurs="unbounded" minOccurs="1">
      <xsd:element name="label" type="label" maxOccurs="1" />
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
    </xsd:choice>
[...]

Und das darf offenbar auch so interpretiert werden:
mindestens eines von:
- ein label das einmal vorkommt
- ein layout das null oder einmal vorkommt

Also ist es valide, da einmal null layout vorkommt. Völlig am Ziel vorbei, aber valide.

Idiotischerweise darf das sogar das hier sein:
<label ..> <label ..> <label ..>

Du hast damit drei label die einmal vorkommen ...

Sobald im Editor jedoch das Kind-Element "label" angelegt wird, kann der Editor speichern.

Da das choice definiert "mindestens eines von label oder layout", was soll der Editor da machen? Er hat keine Ahnung von der Bedeutung der Elemente, und kann deshalb nicht richtig handeln.

Wunsch: Kann der Editor den Endanwender per aussagekräftiger Fehlermeldung auf das fehlende Kind-Element hinweisen?

Gerne. Was wäre denn hier die richtige, verständliche Fehlermeldung?

Grüße,
Julian

[alexbeer]

Hinzufügen von Element RSS via Editor wirft Fehler

Hallo Julian,
habe gerade versucht mit dem Editor das Element RSS hinzuzufügen.

Ich habe hierbei nur die Attribute "src" und "header" mitgegeben, da diese als "required" gekennzeichnet sind.
Beim speichern bekomme ich den Fehler

unknown invalidity: element_bounds_under

Füge ich manuell

      <rss src="https://knx-user-forum.de/external.php?type=RSS2" header="true">
      </rss>

der Config hinzu, ist diese weiterhin valide.
Warum Check_config.php jedoch obigen Beispiel-Code (ohne Label) als valide durchwinkt verstehe ich nicht
In der XSD ist folgendes definiert:

<xsd:complexType name="rss" >
    <xsd:choice maxOccurs="unbounded" minOccurs="1">
        <xsd:element name="label" type="xsd:string" maxOccurs="1" />
    </xsd:choice>

Demnach müsste ja genau ein Label-Element gefordert sein! (s. XML Schema choice Element)

Sobald im Editor jedoch das Kind-Element "label" angelegt wird, kann der Editor speichern.
Wunsch: Kann der Editor den Endanwender per aussagekräftiger Fehlermeldung auf das fehlende Kind-Element hinweisen?

[henfri]

Elemente und Attribute sind getrennte Dinge, und das aus gutem Grund.

Mir ging es um die Reduzierung von Mausklicks. Wenn ich z.B. auf ein Element klicke, können doch die Attribute aller Elemente die Child des Elements sind rechts angezeigt werden.
In meinem Beispiel: Alle Attribute des Label werden rechts angezeigt. Mit einer Überschrift, so dass man weiss, um was es sich handelt. Dabei kann ja weiterhin zw. Attributen und Elementen unterschieden werden.

Referenz-Plattform ist erst mal das Wiregate.

Das war mir nicht bewusst.

CG kann, muss aber nicht funktionieren. Ganz besonders nicht während der Entwicklung.

Ich möchte nur beim Entwickeln/debuggen helfen, wo ich kann. Ich habe nicht das Bedürfnis den Editor zu nutzen, aktuell. Wenn's nicht funktioniert, ok.

In dem Fall unterscheidet sich die PHP-Version (Wiregate hat 5.2.6 mit Suhosin-Patch - bei dir erkenne ich nicht, ob das nur der Patch ist, oder zusätzlich auch die Extension).

Ist die Extenstion nötig?

Ich habe zur bessere Fehlersuche die Ausgabe von save_config.php noch geringfügig erweitert, vielleicht fördert das noch was zu Tage.

server responded with 'parsererror' / 'SyntaxError: JSON.parse: unexpected non-digit'

Hilft das?

Gruß,
Hendrik

[swiss]

Mein Feedback an Hendrik zum Thema Attribute vs. Elemente handelte davon, dass ich es als schädlich betrachtet, Attribute und Elemente wild zu vermengen, und einen Teil der Elemente so darzustellen als wären es Attribute

Nö das halte ich auch nicht für Sinnvoll.Vor allem wenn man zwischendurch doch direkt in der XML arbeitet müsste man dauernd umdenken. Aber wie gesagt. Z.B. Adress ist AFAIK beim Switch Pflicht. Jedenfalls hat der Editor gemotzt, denn ich vergesse regelmässig, dass ich Adress separat anlegen muss

Desshalb der Vorschlag, dass alles was die einzelnen Widgets zwingend an Elementen brauchen (z.B. Adress beim switch) auch automatisch angelegt werden.

[netzkind]

Naja bei Label verstehe ich ja, dass das separat angelegt werden soll. Aber z.B. Adress ist ja für z.B. Switch Pflicht. Da wäre es sinvoll, wenn das erste Adresselement mi tdem erzeugen des Switch gleich mit erzeugt wird. Dann geht es viel wehniger vergessen und es gibt im Nachhinein wehniger unnötige Fragen

Was Plicht ist, sollte automatisch mit dem Widget angelegt werden.

Das sehe ich erst mal genauso.
Das Problem ist: es ist nicht Pflicht, zumindest nicht nach dem XSD.

Mein Feedback an Hendrik zum Thema Attribute vs. Elemente handelte davon, dass ich es als schädlich betrachtet, Attribute und Elemente wild zu vermengen, und einen Teil der Elemente so darzustellen als wären es Attribute.

[swiss]

Naja bei Label verstehe ich ja, dass das separat angelegt werden soll. Aber z.B. Adress ist ja für z.B. Switch Pflicht. Da wäre es sinvoll, wenn das erste Adresselement mi tdem erzeugen des Switch gleich mit erzeugt wird. Dann geht es viel wehniger vergessen und es gibt im Nachhinein wehniger unnötige Fragen

Was Plicht ist, sollte automatisch mit dem Widget angelegt werden.

[netzkind]

Aber das interessiert den User doch nicht ;-)

Den gemeinen Autofahrer interessiert auch nicht der Unterschied zwischen Kraftstoff und Motorenöl, und trotzdem kommt nicht beides aus der gleichen Zapfpistole.

Elemente und Attribute sind getrennte Dinge, und das aus gutem Grund.
Ein Label kann mehr als nur einen Text enthalten (u.a. auch ein Icon), und ein trigger/switch/whatever kann mehr als eine Adresse enthalten.

Debian-Squeeze mit Paketen vom wiregate-repo --> CG-Artig.

PHP 5.3.3-7+squeeze9 with Suhosin-Patch (cli) (built: May  9 2012 07:20:37)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Referenz-Plattform ist erst mal das Wiregate. CG kann, muss aber nicht funktionieren. Ganz besonders nicht während der Entwicklung.

In dem Fall unterscheidet sich die PHP-Version (Wiregate hat 5.2.6 mit Suhosin-Patch - bei dir erkenne ich nicht, ob das nur der Patch ist, oder zusätzlich auch die Extension).

Ich habe zur bessere Fehlersuche die Ausgabe von save_config.php noch geringfügig erweitert, vielleicht fördert das noch was zu Tage.

Grüße,
Julian

[netzkind]

Das wird schwierig, denn die Liste ist vom Design abhängig.

(Eine Liste gibt es noch nicht, ließe sich aber leicht anlegen. Bitte definiere wie es für Dich am geschicktesten ist, sollte halt im jeweiligen Design-Ordner liegen)

Dann wird es schwierig.
Könnte man irgendwie in einen dataprovider reinklöppeln, auch dass der sich aus der Config raussucht welches Design der User grade gewählt hat - fängt aber dann an zu brechen, sobald der User das Design wechselt.

[henfri]

Weil Address und Label eigene Elemente mit eigenen Attributen/Eigenschaften sind.

Aber das interessiert den User doch nicht ;-)
Praktischer wäre es, wenn alles auf einmal angezeigt wird, denn man will doch das ganze Objekt editieren

Hast du ein Wiregate oder ein CG?

Debian-Squeeze mit Paketen vom wiregate-repo --> CG-Artig.

Welche PHP-Version ist installiert?
Funktioniert das Speichern mit dem alten Editor (Release-Version)?

PHP 5.3.3-7+squeeze9 with Suhosin-Patch (cli) (built: May  9 2012 07:20:37)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Das Speichern funktioniert mit der Release-Version.

Ich hab die save_config.php noch mal ergänzt, so dass sie eine Fehlermeldung wirft, wenn das empfangene JSON nicht vernünftig dekodiert werden konnte ... das sollte bei dir jetzt dafür sorgen, dass die Config nicht kaputtgespeichert wird.

Jepp:

configuration could not be saved, server responded with 'configuration-data could not be decoded

Wurde auch nicht berschrieben. Soweit eine Verbesserung.

Alternativ/ergänzend bitte noch mal aus dem Firebug die Antwort von save_config.php suchen und mitteilen (Firebug - Konsole - den POST-Request raussuchen - das Tab "Antwort" kopieren).

{"success":false,"message":"configuration-data could not be decoded"}

Hilft das?

Gruß,
Hendrik

[Chris M.]

Aber wo finde ich eine Liste aller verfügbaren Flavours (hab nicht gesucht)?

Das wird schwierig, denn die Liste ist vom Design abhängig.

(Eine Liste gibt es noch nicht, ließe sich aber leicht anlegen. Bitte definiere wie es für Dich am geschicktesten ist, sollte halt im jeweiligen Design-Ordner liegen)

[netzkind]

Hi Alex,

Habe in den Attributen von "page" noch festgestellt, dass bei "flavour" und auch bei "shownavbar" die Auswahl der möglichen Werte fehlt.

Das mit dem Boolean ist einfach.
Aber wo finde ich eine Liste aller verfügbaren Flavours (hab nicht gesucht)?

@Netzkind: Ist das für dich eigentlich zielführend, alle Bugs hier in diesem Thread zu sammeln, oder hättest du lieber Einträge im Bugtracker(SourceForge.net: Open Automation: Bugs

Den Bugtracker von Sourceforge mag ich nicht besonders. Da es aktuell vor allem ein hin-und-her bei Fehlern ist, finde ich es erst mal nicht verkehrt, das hier im Thread zu machen. Zumindest so lange wie ich noch regelmässig aktiv an der Entwicklung sitze

Grüße,
Julian

[netzkind]

warum wird denn eigentlich z.B. dem Info Element "Address" und "Label" einzeln angezeigt?
Rechts ist doch eigentlich genug Platz, um alle Eigentschaften anzuzeigen.

Weil Address und Label eigene Elemente mit eigenen Attributen/Eigenschaften sind.

Das Speichern schlägt hier übrigens noch immer fehl. Das sollten wir uns nochmal ansehen, oder?

Komisch ist ja, das die Datei geschrieben wird. Es kann also kein Rechte-Problem sein.
Worann kann es dann liegen? Gibt es Bibliotheken, die auf dem Server nötig sind?

Hast du ein Wiregate oder ein CG?
Welche PHP-Version ist installiert?
Funktioniert das Speichern mit dem alten Editor (Release-Version)?

Ich hab die save_config.php noch mal ergänzt, so dass sie eine Fehlermeldung wirft, wenn das empfangene JSON nicht vernünftig dekodiert werden konnte ... das sollte bei dir jetzt dafür sorgen, dass die Config nicht kaputtgespeichert wird.

Alternativ/ergänzend bitte noch mal aus dem Firebug die Antwort von save_config.php suchen und mitteilen (Firebug - Konsole - den POST-Request raussuchen - das Tab "Antwort" kopieren).