icons / mixed-Elemente

[netzkind]

Ahoi,

bei der Entwicklung des Editors bereiten mir derzeit die mixed-Elemente Kopfschmerzen. Mir fällt kein sauberes Darstellungs-Szenario hierfür ein, auch da es nahezu unmöglich scheint, die Reihenfolge und Positionierung der Elemente im Text zu erhalten wenn man das ganze in eine User-taugliche Darstellungsform gepresst hatte (von den Kopfschmerzen abgesehen, im DOM das ganze erst mal auseinandernehmen zu müssen).

Ich möchte deshalb vorschlagen die Konfigurations-Syntax wie folgt zu ändern:

Alt:

  <xsd:complexType name="entry" mixed="true">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="icon" type="icon" />
    </xsd:choice>
    <xsd:attribute ref="value" />
    <xsd:attributeGroup ref="range" />
  </xsd:complexType>

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

  <xsd:complexType name="label" mixed="true">
    <xsd:choice maxOccurs="unbounded" minOccurs="0">
      <xsd:element name="icon" type="icon" />
    </xsd:choice>
  </xsd:complexType>

Neu:

  <xsd:complexType name="entry">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="text" type="xsd:string" />
      <xsd:element name="icon" type="icon" />
    </xsd:choice>
    <xsd:attribute ref="value" />
    <xsd:attributeGroup ref="range" />
  </xsd:complexType>

  <xsd:complexType name="text">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="text" type="xsd:string" />
      <xsd:element name="icon" type="icon" />
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
    </xsd:choice>
    <xsd:attribute ref="align" use="optional" />
  </xsd:complexType>

  <xsd:complexType name="label">
    <xsd:choice maxOccurs="unbounded" minOccurs="0">
      <xsd:element name="text" type="xsd:string" />
      <xsd:element name="icon" type="icon" />
    </xsd:choice>
  </xsd:complexType>

Die drei Elemente entry, label und text wären damit nicht mehr mixed. Inhalte würden durch Kind-Elemente definiert.

Bspw alt:

<text><icon name="CometVisu" type="64" /> Mehrere Icons <icon name="CometVisu" type="64" /></text>

wäre dann:

<text><icon name="CometVisu" type="64" /><text>Mehrere Icons</text><icon name="CometVisu" type="64" /></text>

Fraglich scheint mir noch, wie man die Leerzeichen-Handhabung beim inner-text handhabt (vgl. Beispiel).

Wie ist denn eure Meinung dazu?
Abwärtskompatibilität kann man dadurch "herstellen", dass mit dem Release Upgrade-Skripte bereitgestellt werden, welche die bestehende Konfiguration aktualisieren. Dazu wurde im pages-Element bereits das Attribut lib_version angelegt.

Grüße,
Julian

[JNK]

Hallo Julian,

ist mir eigentlich egal, die Frage ist, ob das ausreichend deterministisch ist. Kann der Editor und vor allem die die Template-Engine garantieren, dass die Reihenfolge gleich bleibt? Im Augenblick (zumindest bei mir), kann ich die Reihenfolge von Text und Bild durch die Reihenfolge der Posititionbierung im label-Element bestimmen. Das wäre schon wichtig.

Gruss,

der Jan

[netzkind]

Hi Jan,

Davon gehe ich schwer aus - sonst wären ja alle Elemente auf der Seite durcheinander

Grüße,
Julian

[Chris M.]

Nun, für manuelle Config-Anpassungen ist das nicht sonderlich schön.

Andererseits machen manuelle Config-Anpassungen nur Experten, normale Anwender nehmen den Editor.

=> Ich bevorzuge den aktuellen Stand, aber wenn der auch nach 1x drüber schlafen und Nachdenken nicht sinnvoll gehalten werden kann, ist das Proposal auch kein Beinbruch.

[netzkind]

[..]aber wenn der auch nach 1x drüber schlafen und Nachdenken nicht sinnvoll gehalten werden kann, ist das Proposal auch kein Beinbruch.

Ich versteh den Satz grade nicht richtig. Wer soll noch mal nachdenken?
Hintergrund: das Thema bewegt mich seit den ersten Gedankengängen zum neuen Editor - bis jetzt dachte ich, da schon relativ viel Nachdenken drauf verwendet zu haben

Da die komplette Datei eine riesige Ansammlung von XML-Knoten ist, sehe ich aber auch nicht wirklich, wieso diese zusätzlichen Knoten jetzt den Editierungsvorgang auf einmal soviel schwieriger machen sollen als er bislang ist.

Im Editor hingegen würde uns das ermöglichen, diese Elemente genau wie alle anderen Elemente als vollwertige Knoten zu betrachten, was bedeutet dass nicht nur Entwicklungszeit gespart wird, sondern ein gleichartiges Vorgehen auch für einen wartungsfreundlicheren, lesbaren und damit weniger fehleranfälligen Code sorgt.

Soviel als Hintergrundgedanken. Für Gegenvorschläge bin ich natürlich offen, aber ich versuche sie schon gegen den Aufwand abzuwägen.

[Chris M.]

Ich versteh den Satz grade nicht richtig. Wer soll noch mal nachdenken?

Ich hatte an Dich gedacht...

Hintergrund: das Thema bewegt mich seit den ersten Gedankengängen zum neuen Editor - bis jetzt dachte ich, da schon relativ viel Nachdenken drauf verwendet zu haben

Na dann ist das durch und die "kein Beinbruch"-Lösung (= Syntax ändern) wohl auf dem Weg

Im Editor hingegen würde uns das ermöglichen, diese Elemente genau wie alle anderen Elemente als vollwertige Knoten zu betrachten, was bedeutet dass nicht nur Entwicklungszeit gespart wird, sondern ein gleichartiges Vorgehen auch für einen wartungsfreundlicheren, lesbaren und damit weniger fehleranfälligen Code sorgt.

Wo im Code müsste ich genau schaun?

AFAIK kann man auch die Text-Teile als ganz normale XML-Knoten verwenden (was sie eigentlich auch sind), man muss nur auf den Typ matchen.

[mumpf]

Fraglich scheint mir noch, wie man die Leerzeichen-Handhabung beim inner-text handhabt (vgl. Beispiel).

Hi, bin zwar kein Experte in dem Bereich, aber dafür ist doch das

 

oder? Das müsste der Editor natürlich können. Oder es gibt noch ein

<space/>

Tag.

Gruß, Waldemar

[netzkind]

AFAIK kann man auch die Text-Teile als ganz normale XML-Knoten verwenden (was sie eigentlich auch sind), man muss nur auf den Typ matchen.

Schau ich mir noch mal an.

[netzkind]

Hmpf. Ist im SVN (rev 1166).

Sollte so funktionieren, aber wer den Quellcode händisch bearbeitet UND im Editor wird möglicherweise über die unterschiedliche Interpretation stolpern.

Ich kann so damit erst mal leben.

[netzkind]

Hi Waldemar,

Hi, bin zwar kein Experte in dem Bereich, aber dafür ist doch das

 

oder? Das müsste der Editor natürlich können. Oder es gibt noch ein

<space/>

Tag.

ein <space /> gibt es nicht, das könnte aber gerne jemand entwickeln, dann kann man Abstände mit fixen Breiten definieren (bspw. 42px - falls jemand versucht seine Visu Pixelgenau zu malen ).

Das mit dem &nbsp; ist richtig, aber so viel HTML-Wissen sollten wir von den Usern nicht erwarten. Aber guter Hinweis, vielleicht kann der Editor das ja transparent von User-Leerzeichen in nbsp; umwandeln ... ich schreib mir das mal auf.

Grüße,
Julian

[Chris M.]

ein <space /> gibt es nicht, das könnte aber gerne jemand entwickeln, dann kann man Abstände mit fixen Breiten definieren (bspw. 42px - falls jemand versucht seine Visu Pixelgenau zu malen ).

Mach keinen Sinn - wer's Pixel genau haben will, soll eine 2D-Seite machen. Die IST Pixel genau. Und bereits möglich!

Das mit dem &nbsp; ist richtig

Da muss ich leider auch widersprechen:

Ein &nbsp; ist ein "non breaking space" - also ein Leerzeichen an dem nicht umgebrochen wird. Verwendet man z.B. um die physikalische Einheit von der Zahl zu trennen ("2" in der ersten und "m" in der nächsten Zeile zu haben ist sehr hässlich).

Das so viele HTML-"Designer" das &nbsp; bis zur Absurdität missbrauchen ist eine andere Geschichte.

[netzkind]

Ein * ist ein "non breaking space" - also ein Leerzeichen an dem nicht umgebrochen wird. Verwendet man z.B. um die physikalische Einheit von der Zahl zu trennen ("2" in der ersten und "m" in der nächsten Zeile zu haben ist sehr hässlich).

Das so viele HTML-"Designer" das * bis zur Absurdität missbrauchen ist eine andere Geschichte.

Vollkommen richtig - noch toller, wenn man das als Ersatz für Tabstops verwendet. Danke dass du das herausgearbeitet hast, nicht dass wir nachher noch als schlechte Vorbilder herhalten müssen

Ich dachte hier jedoch nur daran, leading und trailing spaces als geschütztes Leerzeichen im XML abzulegen - ich kann mir durchaus vorstellen, dass wir ein Szenario gefunden bekommen, in dem man ein Icon und einen Text hat, aber ein bisschen Abstand dazwischen halten will ("egal wieviel, hauptsache es klebt nicht aneinander"). Wenn wir da jetzt die Leerzeichen trimmen, ist das für den User vielleicht nicht mehr nachvollziehbar.

Da können wir als Alternative dann ein "& # 32;" verwenden, also einfach ein Leerzeichen in Unicode-Schreibweise.

Wäre das akzeptabel?

Edit: das Unicode-Zeichen "escaped"