You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Im Anwendungsklassenmodell sollten keine Entscheidungen über die Oberflächendarstellung getroffen werden. MAINFEATURE könnte ggf. ein Hinweis auf einen Primär-/Alternativschlüssel sein, aber keine Information zur Präsentation.
Objekte werden in unterschiedlichen Tabellen oft unterschiedlich detailliert dargestellt: in einer allgemeinen Relationentabelle wird man nur wenige charakteristische fachliche Attribute darstellen, in einer eingebetteten Partnertabelle viele Detailattribute des Partners.
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.
The text was updated successfully, but these errors were encountered:
Dr-Thomas-Tensi
changed the title
Barrakuda: Relationen an der Oberfläche verweisen auf explizite Sichtkomponenten
Barrakuda: Relationen an der Oberfläche sollten auf explizite Sichtkomponenten verweisen
Feb 9, 2018
@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.
The text was updated successfully, but these errors were encountered: