Editor-Entwicklung

[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

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

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]

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.

[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

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

[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

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

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

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

[netzkind]

svn revert -R .;svn up

ist ja für alles

'.' kennzeichnet 'das aktuelle Verzeichnis'. Hier also stattdessen den Dateinamen verwenden, also bspw.

svn revert visu_config.xsd; svn up

[swiss]

Ok. Also steige ich 0 durch

Ich dachte minOccurs = 1 bedeutet, dass dieses Kindelement mindestes 1 mal im übergeordneten Elternelement vorkommen muss...

Wie kann denn 1x0 Label valide sein? Die matematische Regel lautet auch in Amerika 1x0=0 also wäre ja die Bedingug minOccurs=1 nicht erfüllt. Oder verstehe ich den Mechanismus falsch?

[netzkind]

Ok. Also steige ich 0 durch

Ich dachte minOccurs = 1 bedeutet, dass dieses Kindelement mindestes 1 mal im übergeordneten Elternelement vorkommen muss...

Wie kann denn 0x1 Label valide sein? Die matematische Regel lautet auch in Amerika 0x1=0 also wäre ja die Bedingug minOccurs=1 nicht erfüllt. Oder verstehe ich den Mechanismus falsch?

Kurzform: vermutlich ja.

Die Definition sagt einfach aus:
du musst mindestens einmal (xsd:choice minOccurs=1) aus folgender Liste an Optionen exakt eine Option (das ist die Natur von xsd:choice) wählen:
- mindestens ein Label-Element
- mindestens kein Layout-Element

Die Wahl, "na wenn ich schon eines wählen muss, dann nehme ich 'mindestens kein Layout-Element'" ist also eine gültige Wahl.

Noch freakiger wird es ja noch bei maxOccurs im choice. Denn das wird (siehe auch https://knx-user-forum.de/cometvisu/...minoccurs.html) einfach mal garnicht berücksichtigt, denn choice ist ein "eines von".

[swiss]

Ach soo. Das ist eine art ODER verknüpfung...

Entweder
mindestens 1mal Label
ODER
mindestens 0mal Layout

Also legt minOccurs nicht das absolute Mindestvorkommen jedes einzelnen Kindelements im Elternelement fest!? Dass ist natürlich doof. Dann müsste man für die absolut zwingenden Kindelemente noch eine separate Kennzeichnung wie required einführen damit man diese Kindelemente automatisch erzeugen könnte?

[netzkind]

Ach soo. Das ist eine art ODER verknüpfung...

Entweder
mindestens 1mal Label
ODER
mindestens 0mal Layout

Richtig.
Oder als regex: (label{1,}|layout{0,1}){1,}

Also legt minOccurs nicht das absolute Mindestvorkommen jedes einzelnen Kindelements im Elternelement fest!? Dass ist natürlich doof. Dann müsste man für die absolut zwingenden Kindelemente noch eine separate Kennzeichnung wie required einführen damit man diese Kindelemente automatisch erzeugen könnte?

Richtig. Aber dafür bietet XML Schema 1.0 erst mal offenbar nix...