Editor-Entwicklung

[Chris M.]

Grundsätzlich galt zu Anbeginn der Zeit mal die Regel, nicht Kaputtes einzuchecken. Die Idee ist gut, aber - wie man sieht - nicht immer umsetzbar.

2x richtig.

Und wenn sich 2. mit 1. beißt muss man sich halt abstimmen (wie hier ja schon geschehen). Da wir hier in der Entwicklungsversion sind, ist das zwar doof, aber auch nicht weiter tragisch.

[MicHau]

Es wäre mir im Moment garnicht unbedingt Recht, wenn ein zweiter/dritter/vierter am Editor im SVN arbeitet:

Kein Problem, dann lasse ich die Finger davon.

Zu dem folgenden Punkt habe ich aber noch keine Rückmeldung bekommen

...auf

  <xsd:complexType name="text">
[B]    <xsd:sequence>
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="label" type="label" minOccurs="1" maxOccurs="1"/>
    </xsd:sequence>
[/B]    <xsd:attribute ref="align" use="optional" />
    <xsd:attribute ref="flavour" use="optional" />
  </xsd:complexType>

geändert. Damit würde man als erstes ein Layout-Element angeben können und dann den freien Text wie bei einem Label mit Bildern kombinieren. Allerdings habe ich keine Möglichkeit gefunden, dass ohne extra Verschachtelung in einem eigenen Element hinzubekommen. Das Layout-Element mitten im normalen Text wie bisher ist auch keine Alternative.
Der Code akzeptiert auch noch die alte Variante, aber die Validierung gegen das Schema funktioniert nicht mehr für bestehende <text>-Element.

Hat jemand eine Idee, wie man das ohne extra <label>-Element lösen kann, oder kann man diesen Bruch in der Config so akzeptierten?

Wenn es dafür keine andere Lösung gibt, würde ich das dann wieder in die aktuelle XSD einbauen.

[netzkind]

OK, ich kenne den Editor kaum und habe ihn jetzt mal aufgerufen. Dass damit nun nichts mehr funktioniert, hätte ich nicht gedacht. Dann schlage ich vor, diese Schema-Änderungen einfach wieder rückgängig zu machen bis zum Nachziehen des Editors.

Ja, würde ich erst mal vorschlagen.
Der Editor wächst grundsätzlich mit den XSD-Features die eingesetzt werden. Bislang war das in dem Bereich nur xsd:choice und xsd:group - deshalb ist xsd:sequence noch nicht implementiert.

Grundsätzlich galt zu Anbeginn der Zeit mal die Regel, nicht Kaputtes einzuchecken. Die Idee ist gut, aber - wie man sieht - nicht immer umsetzbar.
Ich werde deine Änderungen erst mal zurückdrehen - sobald der Editor dann sequence kann (dazu gibt es bereits Pseudo-Code in meinem Kopf) ist es ja ein leichtes, deine SVN-Revision der XSD wieder rauszuholen.

Wenn es gewünscht ist, kann ich mich gerne an den Editor-Anpassungen beteiligen, müsste mich aber erst einarbeiten, da er bisher für mich ein unbeschriebes Blatt ist (fühle mich halt im XML-Editor sehr wohl )

Es wäre mir im Moment garnicht unbedingt Recht, wenn ein zweiter/dritter/vierter am Editor im SVN arbeitet:
im aktuellen Entwicklungsstadium mache ich relative viele Codeänderungen "im stillen Kämmerlein" und committe die erst ins SVN sobald sie als Milestone abgeschlossen sind/wirken. Die Iterationen sind dabei relativ lang, meist mehrere Wochen. Wenn nun in der Zwischenzeit wesentliche Änderungen am SVN vorgenommen wurden, verbringe ich mehr Zeit damit die mit meiner lokalen Entwicklung zu merge.

Sobald der Editor in den wesentlichen Bestandteilen fertig ist, würde ich es aber begrüßen, wenn sich mehr Leute als nur ich mit dem Code auskennen und sich mit Bugfixes und Features beschäftigen! Ich hoffe diesmal auch einen leserlicheren Codingstil zu haben, als dies beim alten Editor der Fall war

Nachtrag: beim vierten Lesen deines Satzes kann man den auch völlig coding-frei interpretieren: ich bin für jedes Feedback dankbar, und auch für Ideen, Anregegungen, Wünsche, die sich auf den Editor beziehen. Ich werde nicht alle Kommentare umsetzen, aber sie helfen immer, ein klareres Gesamtbild zu sehen! An der Entwicklung kann man sich ja durchaus beteiligen ohne eine Zeile Javascript zu schreiben oder zu verstehen.

Grüße,
Julian

[MicHau]

Den Schritt halte ich für übereilt. Du hast damit für alle SVN-Nutzer den Editor ausgeknockt bis der nachgezogen wurde.

OK, ich kenne den Editor kaum und habe ihn jetzt mal aufgerufen. Dass damit nun nichts mehr funktioniert, hätte ich nicht gedacht. Dann schlage ich vor, diese Schema-Änderungen einfach wieder rückgängig zu machen bis zum Nachziehen des Editors.
Wenn es gewünscht ist, kann ich mich gerne an den Editor-Anpassungen beteiligen, müsste mich aber erst einarbeiten, da er bisher für mich ein unbeschriebes Blatt ist (fühle mich halt im XML-Editor sehr wohl )

[netzkind]

Ich habe die Umstellung auf <sequence> statt <choice> jetzt einfach mal eingecheckt.

Den Schritt halte ich für übereilt. Du hast damit für alle SVN-Nutzer den Editor ausgeknockt bis der nachgezogen wurde.

[MicHau]

Ich habe die Umstellung auf <sequence> statt <choice> jetzt einfach mal eingecheckt. Bei Nicht-Gefallen wird es halt wieder rückgängig gemacht.
Allerdings komme ich mit dem <text>-Element nicht auf einen grünen Zweig.

Ich habe das von

  <xsd:complexType name="text" mixed="true">
[B]    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="icon" type="icon" />
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
    </xsd:choice>
[/B]    <xsd:attribute ref="align" use="optional" />
    <xsd:attribute ref="flavour" use="optional" />
  </xsd:complexType>

auf

  <xsd:complexType name="text">
[B]    <xsd:sequence>
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="label" type="label" minOccurs="1" maxOccurs="1"/>
    </xsd:sequence>
[/B]    <xsd:attribute ref="align" use="optional" />
    <xsd:attribute ref="flavour" use="optional" />
  </xsd:complexType>

geändert. Damit würde man als erstes ein Layout-Element angeben können und dann den freien Text wie bei einem Label mit Bildern kombinieren. Allerdings habe ich keine Möglichkeit gefunden, dass ohne extra Verschachtelung in einem eigenen Element hinzubekommen. Das Layout-Element mitten im normalen Text wie bisher ist auch keine Alternative.
Der Code akzeptiert auch noch die alte Variante, aber die Validierung gegen das Schema funktioniert nicht mehr für bestehende <text>-Element.

Hat jemand eine Idee, wie man das ohne extra <label>-Element lösen kann, oder kann man diesen Bruch in der Config so akzeptierten?

[Chris M.]

..

[MicHau]

Warum muss es eigentlich so kompliziert werden? Wenn man statt <choice> einfach <sequence> verwendet, bekommt man es eindeutig hin, ohne sich abstrusen Schema-Verrenkungen wie XHTML-Schema hingeben zu müssen. Der Preis ist weniger Freiheit bei der Elementreihenfolge; aber ehrlich, wen interessiert das? Wenn ich halt layout vor address schreiben muss, dann mach ich das einfach.

Für die, die ohne Schema-Validierung zufrieden sind, ist das unerheblich, da die Reihenfolge beim XML-Parsen nicht beachtet wird. Für die Editor-Freunde wird das automatisch richtig gemacht.
Ich denke, damit könnte man gut leben.

[swiss]

@Julian:

Ok. Danke für die Erklärung.

Dann bleibt vorerst warscheinlich wirklich nur eine schlüssige Fehlermeldung aber da habe ich auch keine Idee dafür.

Vor allem auch weil die XML Elemente keine "hilfsnamen" haben. Bei einer Übersichtsseite für die Temperaturen habe ich rund 8 diagramm_info hintereinander. Aus denen das Element herauszufinden, dass z.B. mir die Temperatur des Wohnzimmers anzeigt ist sehr schwierig. Könnte man jedem Widget einen Hilfsnamen geben (optional) der im Editor z.B. hinter dem Widgetnamen in Klammern den Hilfsnamen anzeigt, würde dass die übersicht recht vereinfachen.

-Page "Temperaturen"
-diagramm_info (temp_wohnen)
-diagramm_info (temp_bad)
-diagramm_info (temp_zimmer1)
usw...

Eine solche Hilfsfunktion fänd ich manchmal sehr hilfreich.

Wenn man dann noch bei invaliden xml Konfigs im Editor eine Fehlermeldung wie:

Kann Konfiguration nicht speichern.

diagramm_info (temp_wohnen) auf der Seite "Temperaturen" benötigt:

mindestens 1 Adress
oder
mindestens 1 Label

Dann wäre klar wo genau es hackt.

[alexbeer]

ich verstehe das ganze schon als und - oder-Verknüpfung.
Sehe die Ursache in der der Definition im XSD:

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

Sagt aus:

1. RSS muss Min = 1 und MAX = Unendlich viele Kinderelemente vom Type Label oder Layout haben. Folgende Restriktionen sind jedoch weiterhin zu erfüllen:
   1. Label darf Max = 1 x vorkommen (und Min = 1, da dies default ist)
   2. Layout muss Min = 0 und Max = 1 x vorkommen
   
   

Es muss also Bedingung 1. und (1.1 oder 1.2) gültig sein.

Was wäre denn, wenn

<xsd:element name="layout" type="layout" minOccurs="1" maxOccurs="1" />

definiert wäre? Dann müsste doch genau ein Layout oder ein Label enthalten sein, oder?

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

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

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]

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]

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