Beschreibung für Puzzle Workbench - UI

Geometriefeld

Akzeptiert werden Geometrien vom spezifizierten Geom-Typ (sofern konfiguriert) und wenn es Dateien sind, muss es exakt ein Datensatz sein. KBS wird ausgelesen, sofern es irgendwie mit kommt. Fehlt es, muss der Nutzer es noch mit angeben.

Die optionale Konfig sieht wie folgt aus. Es kann einzelner String oder Array sein. Jeder Multi-… schließt automatisch den einfachen Typ mit ein. Es genügt also "MultiPoint" anzugeben, wenn man Point und Multipoint zulassen will.

fieldConfig:

{   
   "geometryTypes": ["Point", "MultiPoint", "LineString", "MultiLineString", "Polygon", "MultiPolygon"]   
}   

{   
  "geometryTypes": "MultiPoint"   
}  

Containertypen

Um Felder in einem Container zu haben, ohne einen Titel anzuzeigen, ist „Standard“ die technisch saubere Wahl.

Möchte man dennoch Feldgruppe oder Panel verwenden und nicht auf den Titel im Editor verzichten, kann noch auf diese Weise einen leerer Titel erreicht werden (unsauber; nur im Notfall machen).

Feldbreiten

In den Einstellungen eines Feldes gibt es „FieldItemConfig“. Dort können in JSON-Notation Angaben zur Steuerung der Breite eines Formularfeldes gemacht werden:

width

Angabe eines Pixel-Wertes (Beispiel: 450 Pixel)

    "width": 450
    "width": { "value": 450, "unit": 0 }

Angabe eines Prozent-Wertes (Beispiel: 65 Prozent)

    "width": { "value": 60, "unit": 1 }

flex

Angabe einer Verhältnis-Zahl, zur Aufteilung des verfügbaren Platzes zwischen nebeneinander angeordneten Formularfeldern.

     "flex": 1

Flex-Werte sollten immer 1 oder größer sein (Dezimalzahlen sind zulässig). Zur Verteilung von 3 nebeneinander liegenden Feldern, die 25%, 25% und 50% des verfügbaren Platzes einnehmen sollen, müssen an den betreffenden Feldern die Flex-Werte 1 – 2 – 1 notiert werden.

minWidth / maxWidth

Im Zusammenspiel mit flexiblen Breiten (Flex oder prozentuale Breiten), kann es sinnvoll sein Mindest- und/oder Maximalbreiten zu setzen. Die Angabe ist immer in Pixeln.

      "minWidth": 200
      "maxWidth": 700

Beispiel 1:

In der Praxis sollte man absolute Pixel-Breiten und Mindestbreiten mit Bedacht verwenden, da sie bei geringerem Platzangebot zu Problemen führen können. Sehr praxistauglich ist dagegen die Verwendung von Flex-Werten in Kombination mit Maximalbreiten (Flex-Werte steuern die prinzipielle Verteilung des Platzes und Max-Werte setzen vernünftige Schranken [wo nötig]).

Beispiel 2:

Alle Formularfelder auf der linken Seite bekommen die gleiche explizite Breite (width). Ein Formularfeld auf der rechten Seite soll den übrigen Platz ausfüllen und bekommt daher einen "flex"-Wert.

Da keine weiteren Formularfelder da sind, die sich um den übrigen Platz "streiten", ist unerheblich, welcher Zahlenwert verwendet wird.

Felder die nebeneinander angeordnet sein sollen, müssen in einen Container, der vom Typ "Standard" sein sollte und ein HBox-Layout hat.

weitere Anmerkungen

Um via Flex eine Aufteilung von 60% zu 40% zu erreichen, müssten Flex-Werte 6 : 4 bzw. 3 : 2 verwendet werden. Bei 2 : 1 wäre die Aufteilung 66,666% zu 33,333%.

Bei einer Aufteilung von 6:4 mittels Flex hat man jedoch den Effekt, das sich die Lücke gleichmäßig auf die Flex-Partner verteilt, so dass die Breite des linken Formularfeldes dann 60% minus Hälfte der Lücke beträgt und dadurch nicht mit darüber liegenden 60% breiten Formularfeldern eine Linie bildet.

Aus diesem Grund bleibt nur die oben genannte Variante "60% + Flex 1" als funktionierende Variante.

Textfeld

Im Layout kann an beliebigen Stellen auch ein Text-Feld eingefügt werden. Die Typdefinition ist dabei wie folgt:

{
    "$type": "IduIT.Core.ReactiveForm.LayoutDef.TextComponentDefinition, IduIT.Core",
    "content": "<b>Hallo, Welt</b>",
    "enableHtml": true,
    "configJson": {
    }
}

Alle Angaben, außer dem $type sind dabei optional. Das configJson entspricht dabei einer IComponentConfig (mit Eigenschaften width, height, flex etc.).

Das Einfügen/Löschen muss z.Z. noch im RawJson erfolgen, der Editor zeigt die Komponente dann mit an.

Lookup-Klassen

Wenn conditions definiert sind, bezieht sich der Wert auf den Feldinhalt. Eine Sonderrolle sind Lookup-Klassen. Dort ist der Wert immer die interne Id des Eintrags.

Beim Übertragen in einen anderen Ikx-Store passen diese Werte dann nicht mehr.

Zur Lösung des genannten Problems kann von der Möglichkeit der Enumerations-Klasse gebrauch gemacht werden.

Definition der Datenklasse

Folgende Bedingungen sind für eine Enumerationsklasse erforderlich:

• An der Klasse muss das Attribut useAsLookup=true und die Bedeutung auf classMeaning="HandleAsEnumerationValue" festgelegt werden
• Es gibt genau eine Entität für die Bedeutung entityMeaning="IsEnumerationField" definiert ist und die vom Typ <SimpleType>Text</SimpleType> sein muss.
• Die Werte in der Enumerations-Entität dürfen keine NULL Werte enthalten und müssen eindeutig sein.

Beispiel:

<?xml version="1.0" encoding="utf-8"?>
<ClassDefintions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.webs.idu.de/cardo3/Ikx/IkxStructure">
  <Class classId="LISTEARTDERPERSON" useAsLookup="true" useHint="CardoPuzzle" classMeaning="HandleAsEnumerationValue">
    <Label>Liste Art der Person</Label>
    <Description />
    <AutoLabelFormat xsi:nil="true" />
    <TabPage>
      <FieldGroup>
        <Entity classEntityId="BEZEICHNUNG" minOccurrance="0" entityMeaning="None" useHint="Unknown">
          <SimpleType>Text</SimpleType>
          <Label>Bezeichnung</Label>
          <Description />
          <AutoLabelIndex>1</AutoLabelIndex>
          <SortHint>020</SortHint>
          <DefinedRights />
        </Entity>
        <Entity classEntityId="SCHL" minOccurrance="0" entityMeaning="IsEnumerationField" useHint="Unknown">
          <SimpleType>Text</SimpleType>
          <Label>Schlüssel</Label>
          <Description />
          <SortHint>020</SortHint>
          <DefinedRights />
        </Entity>
      </FieldGroup>
    </TabPage>
  </Class>
</ClassDefintions>

Verhalten im Formular

Die Werte im Formular sind dann nicht mehr die ID, sondern ein Typ mit der Signatur {key:string,id:number}.

Key ist dabei der Inhalt der Entität, die als IsEnumerationField definiert ist. (wir fanden es besser, hier nicht die Entity-ID zu verwenden, sonder fix "key").

Beispiel, IsEnumerationField ist angegeben ('JUR' ist einer der Werte):

local.TYPANTRAGSTELLER.key == 'JUR'

Gegendarstellung, verhalten ohne Klassendefinition als Enumerationstyp, es kann nur der ID Wert verwendet werden:

local.TYPANTRAGSTELLER == 10

Dies bedeutet: wenn die Klasse auf die Art angepasst wird, dann müssen die Conditions mit angepasst werden.

Im Editor wird bei "Lookupdaten anzeigen" der Key mit ausgegeben.