Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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 ein (Guid) primary key property? Der Name “Id” wird bevorzugt.

  • Haben allen Klassen

    • Eine Caption und PluralCaption für die verwendeten Sprachen?

    • Einen PluralName?

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

  • Haben alle Felder eine Caption für die 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 Klassen definiert?

  • Zeigt ein Blick in ein DB Tool die erwarteten Felder? Fehlen welche oder sind welche zu viel in der DB? Sind alle Namen sinnvoll?

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

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:

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

    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)

  • No labels