Open Dr-Thomas-Tensi opened 6 years ago
@Dr-Thomas-Tensi Ich verstehe deine Bedenken. Du beziehst dich auf die Tabellen (in den Formularen werden meines Wissens alle Felder angezeigt, die die Entität hat - sonst könnte man die Entität ja nicht speichern). Natürlich wäre es dort schön, wenn man im View-Modell (über-)steuern könnte, welche Spalten angezeigt werden. Aber immer alle Attribute anzeigen ist auch keine bessere Lösung in der Praxis. Wir sollten also den Status Quo beibehalten und in der Gruppe mal diskutieren ob wir hierzu neue Sprachelemente im View-Modell einführen wollen.
Ich finde, es gibt eine Asymmetrie in der DSL. Im AWK-Teil gibt es Relationen nur via Pseudoattribute, die Verbindungen zu anderen Typen herstellen, im GUI-Teil gibt es dafür dann eigene Sichtkomponenten, deren Inhalt sich aus den MAINFEATUREs der beteiligten Partner ergibt. Wenn ich Relationen/Assoziationen nicht explizit modelliere, habe ich sofort Probleme wie in #249: ich muss bei Hin-Her-Beziehungen tricksen. Das Issue zeigt zunächst nur, dass die Darstellung von Relationen nicht optimal gelöst ist. Dahinter steckt aber ein weitergehendes Problem, das wir entweder ignorieren oder angehen müssen...
In der Barrakuda-Oberflächen-DSL gibt es Sichtkomponenten für Relationen. Offenbar nutzen diese aus, dass im Anwendungsklassenmodell Attribute mit der Eigenschaft MAINFEATURE versehen wurden. Genau diese Attribute werden in Relationensichten für diesen Typ angezeigt.
Dies ist unpraktisch:
Vorschlag: Relationssichtkomponenten dürfen Bezug nehmen auf Sichtkomponenten für Entitäten und verwenden genau die dort beschriebenen Attribute (siehe Issue 179) in der angegebenen Reihenfolge.