rowe42 / lhm_animad_admin_html5 Goto Github PK

Problem: In der aktuellen Implementierung kann man nur bereits existierende Elemente verknüpfen. Ein wichtiger Usecase wäre es aber, dass man Elemente on-the-fly erzeugen und dann gleich verlinken kann, ohne das aktuelle Element zu verlassen.

Beispiel Verknüpfungselement mit NEU-Button:

Optionen:

1. Beim Klick auf "Neu" wechselt die Oberfläche komplett zum zu erstellenden Objekt (hier: Fall), das teilausgefüllte Objekt bleibt aber temporär gespeichert und man kehrt nach Erstellung wieder zu diesem zurück (das neu erstellte Objekt ist dann automatisch verknüpft).
2. Beim Klick auf "Neu" öffnet sich ein modales Fenster, das den Inhalt des Formulars für das zu erstellende Objekt enthält. Nach Erstellung schließt sich dieses und man ist wieder im teilausgefüllten Objekt (das neu erstellte Objekt ist dann automatisch verknüpft).

Eine Herausforderung für beide Optionen ist Rekursivität, also wenn innerhalb des on-the-fly zu erstellenden Objekts ein weiteres Objekt on-the-fly erstellt werden soll (also bei Option 2 ein modales Fenster oberhalb des modalen Fensters).

So könnte das modale Fenster aussehen:

Fragen:

• Wollen wir Objekterzeugung on-thy-fly über eine der o.g. Optionen realisieren?
• Soll das als fester Bestandteil von Objektverknüpfungen schon mit generiert werden? Wenn ja, soll man in der DSL konfigurieren können, ob man on-the-fly-Objekterzeugung haben will?

Die Tests für die Backend Komponenten sollten (zumindest teilweise) generiert werden. Dafür müssen sie im ersten Schritt implementiert werden. Hier sollte auch ein besonderes Augenmerk auf die Security Tests gelegt werden.

Die Implementierung wird in diesem Ticket erledigt. Für das Erstellen der Templates gibt es das Ticket mdsd / barrakuda 113.

In einer AG-Sitzung habe ich die Security-Tags vorgestellt, die auch in https://github.com/xdoo/lhm_animad_admin_html5/blob/master/src/animad-security-view.html demonstriert sind.

1. Mit common-security-authorize lassen sich ganze Abschnitte in Abhängigkeit der Permissions ausblenden.
2. Mit common-security-check lässt sich ein boolescher Parameter in Abhängigkeit der Permissions setzen.
3. secure-paper-input ist ein von paper-input abgeleitetes Input-Tag, das sich in Abhängigkeit der Permissions auf readonly setzt.

Wir haben noch nicht besprochen, welche Variante nun wie eingesetzt werden soll - insbesondere in der Beispielimplementierung (siehe Issues #71).

Mein Vorschlag:

• Wenn ein Abschnitt gar nicht darzustellen ist (z.B. die Permission "administration_READ_Animal" fehlt), verwenden wir 1.
• Wenn es darum geht, die Felder einer Seite readonly darzustellen (weil wir eine ReadWriteForm verwenden und der Update-Button nicht geklickt wurde), verwenden wir 2. Das hat gegenüber 3. den Vorteil, dass man den booleschen Parameter nur 1x setzen muss und dann überall auf der Seite verwenden kann (und bei der in der Beispielimplementierung angedachten Granularität ist ja entweder die ganze Seite readonly oder eben nicht).
• Den Ansatz, alle Input-Tags als secure-Variante abzuleiten würden wir dann erstmal nicht weiter verfolgen.

Was meint ihr? @xdoo @dragonfly28 @ejcsid @Baumfrosch

Es sollte möglich sein, ein Attribut in der DSL so zu kennzeichnen, dass dies als DB Upload erkannt wird.

Auf der Oberfläche sollte im Formular, das für das Objekt generiert wird ein Upload Feld erstellt werden. Die Datei wird so codiert (z.B. in Base64), dass sie per HTTP Request an die Rest Schnittstelle geschickt werden kann.

Die Restschnittstelle wird so generiert, dass sie binäre Dateien (z.B. Base64 codiert) entgegen nehmen kann. Die Datei wird über JPA in die Datenbank gespeichert.

Wenn man unseren aktuellen Stand mit polymer build baut und dann ein polymer serve im Ordner build/es5-bundled ausführt, kann man die Anwendung zwar ausführen, es kommen aber eine Reihe Fehlermeldungen in die Konsole:

Es sieht so aus, als ob direkt in index.html eingebundene bower-components und davon abhängige Elemente nicht gefunden werden.

Sollten wir irgendwie fixen.

Problem: Bei Objekten mit vielen Feldern wird eine Seite schnell lang und unübersichtlich.
Zur Verbesserung könnte man bei genügend Platz (z.B. Desktop) die Elemente nebeneinander anordnen.

Vgl. https://www.webcomponents.org/element/PolymerElements/app-layout/demo/app-grid/demo/index.html

Optionen

1. Generell ein Grid-Layout festlegen. Elemente werden nebeneinander ansortiert, so lange Platz ist. Damit wird Platz gespart, aber es gibt keine spezifische Semantik, welche Objekte nebeneinander liegen. Dafür könnte man dies auch generell einführen.
2. Fachlich festlegen, welche Elemente nebeneinander gestellt werden sollen. Dazu müsste man aber an generierte Seiten Hand anlegen, um sie zu strukturieren. Dies würde wohl auch die Übergenerierung unmöglich machen (?).

Wenn man mit polymer serve die Anwendung laufen lässt, kann man http://localhost:8081/animals-view aufrufen und refreshen (F5 drücken) und die Seite wird korrekt neu aufgebaut.
Wenn man die Anwendung im Api-Gateway deployed und durch diesen ausliefern lässt, führt dies zu einem Fehler. Offenbar versucht das Api-Gateway, eine entsprechende HTML-Seite in diesem Pfad zu finden, die aber nicht existiert...

Wie wollen wir mit Uploads umgehen?
Soll man ein Upload-Feld modellieren und generieren können oder muss man das von Hand ergänzen?

@xdoo @dragonfly28 @ejcsid

Macht es Sinn, die verschiedenen AJAX-URLs an zentraler Stelle in einem Properties-File o.ä. zu halten? Oder sollen die URLs jeweils direkt in der entsprechenden Komponente hartkodiert werden?

Falls zentral: Wie kommt die URL dann in den nutzenden Tag? Man könnte iron-meta verwenden (https://www.webcomponents.org/element/PolymerElements/iron-meta/elements/iron-meta).

Argumente für zentral:

• alles an einer Stelle gepflegt und übersichtlich
• man kann schnell eine URL anpassen, z.B. wenn ein Service upgedatet wird
• man muss eine URL, die man an mehreren Stellen verwenden will, nur 1x pflegen

Argumente für dezentral:

• vermutlich leichter in der Generierung
• URLs sind dank API-Gateway sowieso alle relativ zur Basis-URL und damit könnte man sie auch als "fachlichen" Teil sehen
• URLs sind wohl meist in den Komponenten verbaut, die man als Entwickler sowieso nicht anfasst

@xdoo @dragonfly28 @ejcsid

Die Komponente <paper-input type="date" ...> zeigt auf meinem Browser (städtischer Firefox 45.9.0) nur ein triviales Textfeld. Scheint der Fallback des Browsers zu sein, wenn kein Date-Picker auf Browser-Seite implementiert ist. Andere Browser (z.B. Safari auf Android) haben hier eigene Controls implementiert und es poppen "Datepicker" auf. Brauchen wir hier eine andere Komponente wie z.B. den um das einheitlicher zu machen oder ziehen wir uns darauf zurück, dass nur angezeigt wird, was die jeweiligen Browser hier zur Verfügung stellen?

Travis gibt folgende Warnung beim Build aus:

html-minify: Unable to optimize /home/travis/build/xdoo/lhm_animad_admin_html5/src/animad-keeper/animad-keepers-list.html { err: 'Parse Error: <paper-search-panel search="{{_search}}" <="" paper-search-panel="">\n </paper-search-panel></paper-item-body>\n <paper-button raised="" on-click="handleNew">New</paper-button>\n <paper-button raised="" onclick="dialogDeleteSelected.open()">Delete</paper-button>\n </paper-item>\n\n <paper-dialog id="dialogDeleteSelected">\n <h2>Delete</h2>\n <p>Do you really want delete all selected items?</p>\n <paper-item>\n <paper-button raised="" dialog-confirm="" on-click="deleteSelectedRows">Yes</paper-button>\n <paper-button raised="" dialog-dismiss="" autofocus="">No</paper-button>\n </paper-item>\n </paper-dialog>\n\n <paper-item>\n <paper-item-body>#</paper-item-body>\n <paper-item-body>First</paper-item-body>\n <paper-item-body>Last</paper-item-body>\n <paper-checkbox on-click="toggleAll" checked="{{_checkedAll}}"></paper-checkbox>\n <paper-icon-button icon="animad-icons:sort"></paper-icon-button>\n </paper-item>\n\n <!--\n // GENERATOR pattern (camel case): [DOMAINNAME][ENTITYNAME]List - id\n // GENERATOR pattern (camel case): [DOMAINNAME][ENTITYNAME] - items\n -->\n <template is="dom-repeat" id="animadKeepersList" items="{{_keepers}}" filter="{{filterKeepers(_search)}}">\n <paper-item>\n <paper-item-body>{{index}}</paper-item-body>\n <paper-item-body>{{item.first}}</paper-item-body>\n <paper-item-body>{{item.last}}</paper-item-body>\n <paper-checkbox on-click="toggleSelection" checked="{{item.checked}}"></paper-checkbox>\n <paper-icon-button icon="animad-icons:delete" on-click="deleteRow"></paper-icon-button>\n </paper-item>\n </template>\n\n <array-selector id="selector" items="{{_keepers}}" selected="{{selected}}" multi="" toggle=""></array-selector>\n\n <template is="dom-repeat" items="{{selected}}"></template>\n<!--// TBD: Dummy, muss wieder raus -->\n\n <template is="dom-repeat" id="selected" items="{{selected}}">\n <paper-item>\n <paper-item-body>{{item.first}}</paper-item-body>\n <paper-item-body>{{item.last}}</paper-item-body>\n </paper-item>\n </template>\n\n </template>\n\n <script src="animad-keepers-list.html_script_0.js"></script>\n\n </dom-module>' }

Siehe: https://travis-ci.org/xdoo/lhm_animad_admin_html5

Die von Barrakuda generierten MS bekommen derzeit ein Token, das vom eigenentwickelten Auth-Server kommt. Es ist zu prüfen, inwieweit hier Anpassungen vorzunehmen sind, wenn stattdessen KeyCloak angebunden wird.

Zudem wird die Autorisierung ebenfalls (und offenbar bei jedem Zugriff auf den MS) vom User-Endpoint des Auth-Servers geholt. Wir wollen das mit dem KeyCloak ja etwas anders machen (Entitlements-API von KeyCloak verwenden, Permissions beim ersten Zugriff des Users holen und cachen), was man exemplarisch ins Backend einbauen muss und dann auch mit in die Generierung übernehmen muss.

Es stellt sich architekturell die Frage, ob alle MS den KeyCloak direkt per Entitlements-API aufrufen (über das authorisationLib.jar, das ich schon erstellt habe), oder über einen neu zu erstellenden User-MS, der als eine Art Proxy zum KeyCloak fungiert. Insbesondere vor dem Hintergrund, dass wir vom Frontend aus ebenfalls Zugriff auf die Permissions des aktuellen Users brauchen (da möchte ich aber auch die authorisationLib verwenden und nicht das gleiche nochmal in JS nachbauen).

Beim öffnen der Seite taucht folgende Fehlermeldung in der Konsole auf:

[...]
TypeError: script is null
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Polymer is not a function
TypeError: Super expression must either be null or a function, not undefined
[...]

Das Problem ist bekannt: https://github.com/Polymer/polymer-cli/issues/905

Lösung:

{
  [...]
  "builds": [
    {
      "bundle": {
        "excludes": ["bower_components/webcomponentsjs/webcomponents-loader.js"]
      }
      [...]
    }
  ]
  [...]
  }
}

Wir haben uns vorgenommen, die Anforderung des OWASP ASVS durchzugehen mit der Absicht, mit der Referenzarchitektur mindestens Level 2 zu erfüllen.

Dieses Issues dient als Merker für dieses Arbeitspaket. @Baumfrosch @xdoo @dragonfly28 @ejcsid

Bisher habe ich die Security-Tags so implementiert, dass sie eine flache Liste von Permissions vom Backend holen:

[
    "RESOURCE2",
    "RESOURCE3",
    "RESOURCE1",
    "Default Resource"
]

(zukünftig entspricht das dann "administration_READ_Animal", "administration_WRITE_Animal" usw.)

In Issues #36 schlagt ihr vor, alle Requests im HAL-Format zu haben. Das sollte dann wohl auch für das Abholen der Permissions gelten, auch wenn diese nicht aus der Datenbank, sondern letztlich von KeyCloak kommen?

Das würde dann wohl so aussehen:

{
  "_embedded": {
    "permissions": [
       "RESOURCE2",
       "RESOURCE3",
       "RESOURCE1",
       "Default Resource"
    ]
  },
  "_links": {
    "self": {
      "href": "http://localhost:39146/permissions"
    },
    "profile": {
      "href": "http://localhost:39146/profile/permissions"
    },
    "search": {
      "href": "http://localhost:39146/permissions/search"
    }
  }
}

Richtig? Würde es die Links self, profile und search auch geben?

Würde das nämlich dann gleich entsprechend ändern wollen, dass die Tags diese Form verarbeiten können.

@xdoo @dragonfly28 @ejcsid

Im unserem Zoo-Beispiel und auch im Generator wird bislang ausschließlich das linke Menü verwendet. Man könnte aber auch das Top-Level-Menü, das rechte, das untere Menü oder den FAB verwenden: https://material.io/guidelines/layout/structure.html#structure-ui-regions (siehe Desktop)

Fragen:

• Wollen wir weitere Menüs einsetzen? Wenn ja, welche und fachlich für welchen Zweck? Vgl. auch Issue #54
• Je nach Entscheidung: Soll das auch im Generator berücksichtigt werden?

Wir sollten die Oberfläche frühzeitig auf I18N umstellen (damit man das konsequent für alle Oberflächenelemente mitdenkt) und die Oberfläche nach deutsch übersetzen.

Wir müssen noch definieren, nach welchen Gesichtspunkten eine Anwendung in einzelne Microservices geschnitten werden soll.
Dies muss man einerseits generisch machen (Diskussion der Empfehlungen aus der Community, z.B. striktes DDD nach Eric Evans), andererseits kann es auch helfen, es frühzeitig am Beispiel BeZweck auszuprobieren - dazu sollte aber das technische Datenmodell vorliegen (vgl. #69).

Dieses Issue dient als Merker für dieses Arbeitspaket.

Aktuell wird die Auswahlliste bei Relation Elementen einfach als Liste angezeigt. Dies soll von aussen konfigurierbar sein. Eine mögliche Lösung sind CSS Mixins in Verbindung mit css grid.

In älteren Browsern kommt folgende Fehlermeldung, beim öffnen eines Dropdowns:

No web animations detected. This element will not function without a web animations polyfill.

Siehe dazu https://github.com/PolymerElements/paper-dropdown-menu/blob/2.0-preview/README.md#changes-in-20

Die Information der Nutzer über Toasts sollte in ein eigenes Mixin ausgelagert werden, dass bei Bedarf verwendet werden kann. Grund ist, dass man potenziell an unterschiedlichen Stellen auf die Toasts zurückgreifen will. In der Regel immer dann, wenn man eine Kommunikation mit dem Backend hat und diese nicht funktioniert. Da muss man zwar auch auf die Konsole loggen, aber den Nutzer sollte man ebenfalls über das Problem informieren.

Wenn wir in der Tabelle / Liste Paginierung einsetzen wollen, dann muss dies vom Backend über HATEOAS / HAL unterstützt werden. Aktuell ist dies nicht so.

The lhm_animad_admin_service is ready to use now - next step is to connect the Ui with the REST API of the service;

• is the iron-ajax component sufficient?
• is it worth to investigate in the fetch API?
  see -> https://fetch.spec.whatwg.org/
  see -> https://developers.google.com/web/updates/2015/03/introduction-to-fetch

Wird die Liste anders sortiert, dann wird der falsche Datensatz gelöscht, wenn über Papierkorb gelöscht wird.

Die HATEOAS Links sollten verwendet werden, um Schaltflächen bei Standadkomponenten ein, bzw. auszublenden. Dies ist nicht als Alternative zum Berechtigungssystem auf der Oberfläche zu verstehen. Dies wird nach wie vor benötigt, da die Links auf Serverseite ja nicht unter Berechtigungsgesichtspunkten erstellt werden. Diese Maßnahme dient primär dazu, die Anwendung leichter wartbar zu machen, da wir nur noch einen Basislink benötigen und alle anderen Links werden jeweils durch die Serverkommunikation geliefert. Aus meiner Sicht erleichtert dies den Betrieb auf einer Container Infrastruktur sehr.

Wir brauchen die Möglichkeit, in einer großen Anzahl von Objekten zu suchen – entweder in einem Google-artigen Freitextfeld oder typisiert (siehe ForeUI-Mockup → Fallanlage).

Unsere Tabelle hat schon ein Suchfeld. In welchen Feldern sucht dieses? Wie kann man hier steuern, z.B. wenn man nur in einer Spalte suchen will?

Vielleicht könnte man ein Search-by-Example in die Spaltenüberschrift einbauen (kann vaadin-grid, siehe https://www.webcomponents.org/element/vaadin/vaadin-grid/demo/demo/index.html, Sorting-and-Filtering)?

Dieses sollte sich aber - anders als im Beispiel - immer noch kombinieren lassen mit Sortierung der Spalten, so dass man auch ein gefiltertes Ergebnis noch sortieren kann.

@ejcsid

Problem: Bei Objekten mit vielen Feldern wird eine Seite schnell lang und unübersichtlich.
Man könnte ein Menü rechts einblenden, in dem die Struktur der Seite anhand der Überschriften der Abschnitte abgebildet ist und man beim Klick zur entsprechenden Stelle springt.

Fragen:

• Wollen wir so eine Art Seitennavigation einführen? Wollen wir dafür ein Menü rechts verwenden?
• Wie soll sich das Menü im mobilen Fall verhalten? Ausgeblendet werden?
• Soll die Seitennavigation mit generiert werden? Wenn ja, für alle Seiten oder nur für lange Seiten? Wenn ja, wie ist "lang" definiert?

Beim Zurücksetzen eines Formulars müssen die Relationen gelöscht werden. Aktuell werden lediglich die Formularfelder gelöscht. Die Relationen bleiben stehen. Hier muss ein Event ausgelöst werden, dass im Relation Element (bzw. der dazugehörigen Behavior) verarbeitet werden kann

In älteren Browsern (Firefox 45.9) wird hier nur ein Textfeld angezeigt. In Chrome (v51) geht hier die ANzeige mit dem im Label angezeigten Format auseinander.

aus

<paper-input
    type="date" 
    name="employmentdate" 
    required 
    label="Einstellungsdatum (yyyy-mm-dd)" 
    value="{{data.employmentdate}}" 
    auto-validate 
    required 
    pattern="[0-9]{4}-[0-9]{2}-[0-9]{2}">
</paper-input>

wird in Chrome

Pagination als Option eingeführt, aber in diesem Fall werden nur die Datensätze der jeweiligen Seite sortiert (siehe: vaadin-grid issues: 1051). Vaadin hat diesen issue akzeptiert und wird ihn umsetzen.

Wenn wir für ein Objekt Relationen haben, dann benötigen wir in der Payload (HAL) einen Link, über den neue Relationen hinzugefügt werden können. Bei Enclosures schaut das aktuell so aus:

{
  "name": "Elephant's Paradise",
  "cleaningTime": "15:15:15",
  "_links": {
    "self": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5"
    },
    "enclosure_": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5"
    },
    "animalList": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5/animalList"
    }
  }
}

Es müsste aber so aussehen:

{
  "name": "Elephant's Paradise",
  "cleaningTime": "15:15:15",
  "_links": {
    "self": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5"
    },
    "enclosure_": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5"
    },
    "animalList": {
      "href": "http://localhost:39146/enclosures/3bca5b38-13be-4fd3-b656-fa79a639ddd5/animalList"
    },
    "animals": {
      "href": "http://localhost:39146/animals"
    }
  }
}

Problem: Bei Objekten mit vielen Feldern wird eine Seite schnell lang und unübersichtlich.
Eine Möglichkeit wäre es, einzelne Abschnitte mit "Collapse-Buttons" zu versehen, damit sie der User zur besseren Übersicht einklappen kann (siehe z.B. https://www.webcomponents.org/element/Collaborne/paper-collapse-item oder https://www.webcomponents.org/element/jifalops/iron-collapse-button).

Beispiel:

Fragen:

• Sollen Collapse-Buttons zum Einsatz kommen?
• Soll der Generator einen Collapse-Button standardmäßig mit generieren? Oder soll ein Collapse-Button via DSL konfigurierbar sein (dazu müsste die DSL angepasst werden)? Wenn ja, soll der Bereich standardmäßig auf- oder zugeklappt sein?
• Was soll im zugeklappten Modus standardmäßig zu sehen sein? z.B. immer die Überschrift des Bereichs?

Wenn die Services auf Openshift betrieben werden, dann fallen Registry und Config Server weg. Die Hystrix Clienst funktionieren auch etwas anders.

Bisher existieren die Security-Tags nur als Showcase auf einer eigenen Seite. Wenn wir nun den in Issues #71 definierten Showcase implementieren, sollte das auch die Security-Tags beinhalten.

Ich würde die Permissions dann als Mock bei Mockable.io hinterlegen, damit wir dafür erstmal noch kein Backend brauchen.

Nach Abstimmung mit @Baumfrosch soll das bestehende BeZweck Datenmodell vom TRE unter Unterstützung durch mich und Helmut im Rahmen des technischen Datenmodells so ummodelliert werden, dass die generischen Entities wie "Fall" und "Aktivität" in verschiedene Entitäten aufgebrochen werden, um abhängige Elemente (wenn Fall-Type X dann wird Feld Y benötigt) zu vermeiden.

@Baumfrosch hat sich bereiterklärt, den dann vorliegenden Entwurf mit seiner Expertise zu betrachten und ggf. noch zu überarbeiten.

Dieses Issue dient als Merker für dieses Arbeitspaket.

Es sollte möglich sein, ein Attribut in der DSL so zu kennzeichnen, dass dies als DMS Upload erkannt wird. Zu überprüfen ist, ob man die als Mainfeature gekennzeichneten Attribute als Metadatum abspeichert.

Auf der Oberfläche sollte im Formular, das für das Objekt generiert wird ein Upload Feld erstellt werden. Die Datei wird so codiert (z.B. in Base64), dass sie per HTTP Request an die Rest Schnittstelle geschickt werden kann.

Die Restschnittstelle wird so generiert, dass sie binäre Dateien (z.B. Base64 codiert) entgegen nehmen kann.

Im Service kann der Programmierer dann weitere Metaddaten hinzufügen, bzw. beliebige Dinge mit der Datei machen (wird nur initial generiert). Von dort aus ruft er den EAI Artefakt Richtung DMS auf.

Konsequenter Weise muss ein DMS EAI Artefakt generiert werden, wenn ein DMS Upload im Modell enthalten ist.

Aktuell hat der Menübutton links oben keine Funktion.

Auch die Read/Update Formulare benötigen die Möglichkeit Relationen zu bearbeiten. Hier sollte die Sichtbarkeit der Relationselemente AUCH daran hängen, ob die Datenstruktur bereits eine Relation beinhaltet. D.h. selbst wenn das Sichtbarkeitsproperty für eine Relation auf 'false' gesetzt ist, sollte die Relation gesehen, bzw. bearbeitet werden können, wenn in der Datenstruktur Relationen vorhanden sind.

Für die Formulare müssen noch (JavaScript) Tests erstellt werden. In diesem Rahmen ist zu prüfen, inwieweit es sinnvoll ist Tests gleich mit zu generieren.

Aktuell ist die Oberfläche noch nicht in der Lage mit dem generierten Backend zu kommunizieren. Hierzu muss die Oberfläche in die Lage versetzt werden, das HAL Format zu verstehen.

Wenn in i18n aktuell ein Fehler auftritt, dann wird das gesamte Formular nicht dargestellt. Es sollte zumindest so sein, dass der Nutzer das Formular sieht, auch wenn die i18n keys nicht aufgelöst werden konnten.

Navigiere zu einer Seite > 1, filtere die Datensätze, so dass weniger Seite angezeigt werden als die aktuelle Seite. Folge: Es wird eine leere Seite angezeigt.

Vorschlag, die Liste soll in diesem Fall auf die erste Seite springen.

Ich halte den Einsatz von Icons für sehr sinnvoll. Icons können schnell erfasst werden und ersparen einem die Internationalisierung. Für Sachbearbeiter ist die Internationalisierung nicht so spannend, im Hinblick auf eGov wird das aber zu einer echten Herausforderung.

Wenn ihr auch der Meinung seid, würde ich das Thema mal angehen und versuchen ein paar Vorgaben zu machen.

Hier eine interessante Antwort auf eine Stadtratsanfrage zu mehrsprachigen Hinweisschildern:
"Der Vorteil von Piktogrammen ist, dass sie unabhängig von Sprache und Herkunft von allen Personen gleichermaßen verstanden werden. In München leben Menschen aus über 180 Nationen, die mehr als 43 verschiedene Sprachen sprechen. Nicht alle von Ihnen können wir mit einem für sie verständlichen Texthinweis erreichen und die Auswahl bestimmter Sprachen würde immer zu einer „Benachteiligung“ der anderen führen. Daher sind fremdsprachige Texthinweise aus Sicht des Bürgerbüros keine
gewinnbringende Alternative oder Ergänzung zu den universell verständlichen Piktogrammen. Dies vor allem auch, weil die Erfahrungen im Parteiverkehr zeigen, dass das Angebot auch von fremdsprachigen Kundinnen und Kunden tatsächlich sehr gut verstanden und angenommen wird.

Bisher haben wir nur enzelne Aspekte des Zoo-Beispiels in Polymer implementiert. Ich fände es aber wichtig, das Zoo-Beispiel vollständig oder zu einem ausreichend großen Teil zu implementieren, damit man sieht, wie das Generierungsergebnis aussehen soll.

Die DDL und GUI-DDL finden sich im Gitlab hier:
.../mdsd/barrakuda/wikis/demo

Vorschlag: Wir implementieren es wie beschrieben, aber lassen die "Enclosures" weg, also nur die "Animals" und "Keepers". Alles was zu "Enclosures" gehört (also auch die Views) nehmen wir weg. Das reduziert die Aufgabe, hat aber immer noch alle relevanten Bestandteile, z.B. Relationen, Komponenten auf einer Seite, verschiedenartige Feldtypen.

Voraussetzung ist, dass wir die Bestandteile (z.B. die Table) soweit sauber implementiert haben.

Bitte kurze Meinung dazu - ich würde dann die entsprechend abgespeckte DDL hier posten und auch gerne Teile der Umsetzung übernehmen.

@dragonfly28 @ejcsid @Baumfrosch

Problem: Bei Objekten mit vielen Feldern wird eine Seite schnell lang und unübersichtlich. Eine optische Trennung von Absätzen würde die Lesbarkeit / Bedienbarkeit erhöhen.

Dabei gibt es die Optionen:

1. Cards (Beispiel: https://expandjs.com/components/mat-toast)
2. Dividers
   
3. Andere?

Fragen:

• Benötigen wir eine optische Trennung von Absätzen? Welche der o.g. Optionen sollen zum Einsatz kommen?
• Soll dies bereits mit generiert werden? Müssen wir dazu die DSL erweitern oder lässt sich das mittels der bestehenden DSL modellieren (Idee von Claus im AG-Meeting: Jeder zu separierende Abschnitt als eigenes "component" modellieren und damit auch eine eigene "form" modellieren).

Beim Deployment auf Github Pages ist nur eine graue Seite zu sehen
-> https://dragonfly28.github.io/lhm_animad_admin_html5/

Folgende Meldung erscheint in der JS Webkonsole:
Registrieren/aktualisieren eines ServiceWorker für Gültigkeitsbereich 'https://dragonfly28.github.io/' ist fehlgeschlagen: Laden des Skriptes 'https://dragonfly28.github.io/service-worker.js' mit Status 404 fehlgeschlagen.
TypeError: ServiceWorker script at https://dragonfly28.github.io/service-worker.js for scope https://dragonfly28.github.io/ encountered an error during installation.

Nach meinem Verständnis ist das API-Gateway eine neue Komponenten, die es so derzeit im Barrakuda-Generat nicht gibt. Müssen wir also initial entwickeln (dabei zunächst noch das richtige Produkt auswählen - vgl. hierzu Diskussion in Issues #80) und in Barrakuda einbauen (lassen).

Hierbei muss auch gleich die Frontend-Integration ins KeyCloak (vgl. auch Issues #88) mit erstellt werden.