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
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.
The text was updated successfully, but these errors were encountered:
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?
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...
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:
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.
The text was updated successfully, but these errors were encountered: