Page Comparison

...

Dies Checkliste mit all ihren Regeln bildet einen Styleguide für das Erstellen von Modellen. Die Ziele sind:

• Möglichst klar strukturierte Modelle

• Möglichst einfache Lesbarkeit

• Bekannte Muster antreffen und sich in anderen Modellen zuhause fühlen

Klassen

• Haben alle Klassen eine ein (Guid) Id?primary key property? Der Name “Id” wird bevorzugt.

• Haben allen Klassen eine

  • Eine Caption und PluralCaption für

  Deutsch und Englisch

  • die verwendeten Sprachen?

  • Einen PluralName?

• Haben alle Text-Felder eine Länge definiert?

• Haben alle Felder eine Caption für Deutsch und Englischdie verwendeten Sprachen?

• Haben alle Klassen Default-Sortierungen

• Sind alle nötigen (unique) Indexes definiert worden?

• Sind die Required-Felder entsprechend definiert?

• Sind alle Relationen zwischen den neuen und zu den bestehenden Klassen definiert?

• Zeigt ein Blick in ein DB Tool die erwarteten Felder? Fehlen welche oder sind welche zu viel in der DB? Stimmen Sind alle Namen ?Code: Werden die Elemente in der Reihenfolge Classes, Paths, Properties definiertsinnvoll?

Ansichten

• Haben alle Klassen mindestens ein Title-Layout?

• Reichen die Informationen aus dem Title-Layout aus um das Objekt klar zu identifizieren?

• Haben alle Klassen die in einer Liste angezeigt werden mindestens ein List-Layout?

• Reichen die Informationen in den List-Layouts aus um die Objekte zu identifizieren und um die wichtigen Vergleiche zwischen den Objekten anzustellen?

• Haben alle Klassen für die ein Detail angezeigt wird mindestens ein Detail-Layout?

• Sind die Informationen im Detail-Layout sinnvoll sortiert und gruppiert?

  • wichtige Wichtige Infos zuerst?

  • Pflichtfelder sollten eine Validierung beinhalten.

  • Keine Pflichtfelder in zusammenklappbaren Gruppen platzieren.

  • Sind zusammengehörige Infos in nahe beieinander?

  • Falls zu viele Infos für einer Seite, Tabs eingesetzt?

  • Sind die Detail-Layout im Vergleich mit anderen Detail-Layouts konsistent beschriftet und aufgebaut?

  • Werden je nach Status/Datenlage unnötige Felder ausgeblendet?

  • Sind nur dort Captions definiert wo es auch wirklich nötig ist?

  • Werden wo möglich bestehende Captions/PluralCaptions von Klassen verwendet?

• Code: Werden die Layouts in der Reihenfolge Title, List, Detail definiert?

• Siehe auch Leitfaden Ansichten-Aufbau

Menü (Hauptnavigation)

• Menu Einträge: Optional Menu Item Caption setzen, fallse diese nicht aus dem Target bezogen werden soll. Falls gesetzt, dann sollte die Caption in allen verwendeten Sprachen gesetzt werden.

Sollte die Menu Item Caption nicht gesetzt und das Target eine Liste sein, wird die Plural Caption der Liste verwendet. Sollte das Target ein Detail sein wird die Detail Caption verwendet.

Regeln für Codierung

Reihenfolge in der Builder Datei

Bitte die folgende Reihenfolge beachten:

1. AddClasses

2. AddPaths

3. AddProperties

4. AddLayouts - wo dies benötigt wird

Code Style

Builder stellt ein Fluent-API zur Verfügung. Für die Bessere Lesbarkeit

• Builder.Add.Xxx... Add mit auf der Builder Zeile

  • Danach weitere Enrichments auf neue Zeile

• Reihenfolge Enrichments: DB relevante Einstellungen wichtiger darum zuerst.

  • Eher Oben

    • Id

    • Transient

    • IsNotNullable

    • Default

  • Eher runter

    • Visibility

    • Captions

      • Immer gleiche Reihenfolge der Sprachen - konsistent z.B. 1. en 2. de

• keine doppelte Leerzeilen. Wenn nötig evtl. noch Kommentar über Abschnitt

• Wann immer möglich keine eigenen Parser verwendet. Stattdessen immer die vorhandenen Builder-Methoden für Expressions verwenden. Fehlende Methode melden. Falls ein Parser verwendet werden muss, immer den “Strict”-Mode verwenden!

AddClasses(…)

Hier werden die Klassen in der folgenden Reihenfolge definiert

• normalen Klassen

• Enum-basierten Klassen

definiert.

AddPaths(…)

Add.Relation -> fügt Relation-Properties (Hin- und Rückrichtung) und indirekt einen Path ins Model ein. Falls Relationen mit Daten-Ownership (Cascading) daherkommen, dann solle die Relation in der Klasse definiert werden, welche die Daten besitzt.

AddProperties(…)

• MetaType.Text immer mit Länge, ausser Property ist transient oder calculated.

• Einstellungen für Properties werden in folgender Reihenfolge gesetzt;

  • NotNull

  • Transient

  • Alles was in dieser Liste nicht definiert ist, sortiert danach, wie stark die Datenbank davon beeinflusst wird

  • Control

  • Caption (Immer Englisch und Deutsch setzen, mit Englisch zuerst)

  • Description (Immer Englisch und Deutsch setzen, mit Englisch zuerst)

  • Instruction (Immer Englisch und Deutsch setzen, mit Englisch zuerst)

  • Configure / ListConfiguration

• Reihenfolge - Alle nacheinander

  1. Properties, CalculatedProperties

  2. Actions, Sorts, Index

  3. Breadcrumbs

• Falls Properties für mehrere Klassen definiert werden Kommentare für Abtrennung verwenden:
  

  Code Block
  // Person Elements.Person.Add("Name", MetaType.Text, 100) ... // Addresse Elements.Adresse.Add("Strasse", MetaType.Text, 100) ...

AddLayouts(…)

• Reihenfolge der Layouts

  • Title

  • List(s)

  • Detail(s)

• Wenn das Layout in einem separatem Builder erstellt wird, wird von der CuiSandboxLayoutBuilderBase Klasse geerbt.

• In Layouts keine zusätzlichen Core-Elemente definieren (Properties, Relations, Actions)

• In den normalen Klammern des using Statements werden keine Einstellungen gesetzt, wie zB. Caption, diese werden innerhalb des Codeblockes am Anfang gesetzt.

• In C# zur Sicherhet immer die klassische Form anwenden:

  Code Block
  using(var layout = …)) { layout.Add.Link(…) }

• Wenn das Layout in einem separaten Builder erstellt wird immer die generierten Metadaten verwenden.

• Wenn die AddLayouts Methode sehr gross wird, können die List, Title, Detail und Graphic Layouts in einzelne Methoden ausgelagert werden, dabei ist folgende Reihenfolge einzuhalten;

  • AddTitle(metadata, elements)

  • AddLists(metadata, elements)

  • AddDetails(metadata, elements)

  • AddGraphics(metadata, elements)