Versions Compared

Old Version 4

changes.mady.by.user Remo von Ballmoos

Saved on

compared with

New Version Current

changes.mady.by.user Sebastian Greulach

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 die verwendeten Sprachen?

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

...

  • 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

...

  • 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)
...

...

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