Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Barrakuda: Relationen an der Oberfläche sollten auf explizite Sichtkomponenten verweisen #180

Open
Dr-Thomas-Tensi opened this issue Feb 8, 2018 · 2 comments
Assignees
Milestone

Comments

@Dr-Thomas-Tensi
Copy link
Collaborator

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.

@rowe42 rowe42 added this to the RefArch_2.0 milestone Feb 9, 2018
@Dr-Thomas-Tensi 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
@rowe42 rowe42 modified the milestones: RefArch_2.0, RefArch_3.0 Mar 23, 2018
@rowe42
Copy link
Owner

rowe42 commented Mar 28, 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.

@rowe42 rowe42 modified the milestones: RefArch_3.0, RefArch_4.0 Mar 28, 2018
@Dr-Thomas-Tensi
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants