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: Ergänzung der Oberflächen-DSL um explizite Attributnamen #179

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

Comments

@Dr-Thomas-Tensi
Copy link
Collaborator

Derzeit gibt es in der Barrakuda-Oberflächen-DSL Sichtkomponenten, die auf Entitäten verweisen. Die Anordnung der Attribute in der Sicht ist gegeben durch die im Anwendungsklassenmodell.

Dies ist unpraktisch:

  • Die Anordnung im Anwendungsklassenmodell wird meist nach anderen Gesichtspunkten gemacht als das Oberflächendesign.
  • In manchen Sichten möchte man nicht alle Attribute sehen, in anderen schon.

Vorschlag: die Sichtkomponenten im Oberflächenklassenmodell enthalten eine Liste von Attributnamen, die per Namen auf die unterliegende Anwendungsklasse gematcht werden. Wenn die Liste leer ist, wird die Liste aus dem AKM genommen.

@rowe42 rowe42 added this to the RefArch_2.0 milestone Feb 9, 2018
@ejcsid
Copy link
Collaborator

ejcsid commented Mar 16, 2018

Reihenfolge der Attribute kann über CSS angegeben werden.
Attribute für die Tabelle werden über MAINFEATURE angegeben.
In den Formularen werden alle Attribute angezeigt. Warum sollen dort nicht alle Attribute angezeigt werden?

@ejcsid ejcsid modified the milestones: RefArch_2.0, RefArch_3.0 Mar 16, 2018
@rowe42
Copy link
Owner

rowe42 commented Mar 28, 2018

@Dr-Thomas-Tensi Kannst du dir den Kommentar von @ejcsid bitte nochmal ansehen und überdenken, ob wir dieses Issue schließen können?

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

Der derzeitige Stand der GUI-DSL ist aus meiner Sicht einfach nicht besonders modular: es gibt zwei Ebenen von Definitionen, eine Wiederverwendung von Teilsichten ist nicht vorgesehen. Meine Erwartung wäre, dass man z.B. sagen kann: ein Tier hat normalerweise die Attribute (r,s,t), aber es gibt auch eine erweiterte Ansicht (r,s,t,x,y). Das könnte man über eine stärker modularen Ansatz mit hierarchischen Sichtkomponenten und expliziter Angabe von Attributen! gut lösen.

Ich finde auch unlogisch, dass - wie von @ejcsid beschrieben - diverse Oberflächenentscheidungen nicht in der GUI-DSL abgedeckt sind:

  • Die Auswahl der Spalten einer Tabelle werden über einen Stereotyp MAINFEATURE im Anwendungskernmodell festgelegt (und das für alle Verwendungen dieses Typs in einer Tabelle).
  • Die Reihenfolge der Elemente in einem Objektformular ist standardmäßig über die Definitionsreihenfolge im Anwendungskernmodell gegeben und wird ggf. über einen Layoutmechanismus innerhalb eines Style-Sheets umdefiniert.
  • Es sind in einem Objektformular immer alle Attribute aus dem AWK-Modell sichtbar, es sei denn man filtert das via CSS aus.

Daraus schließe ich, dass man über eine Überarbeitung der GUI-DSL nachdenken sollte. Ob das jetzt kurzfristig passieren soll, sollten wir diskutieren. Vielleicht brauchen wir aber @Baumfrosch dazu...

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