
053: Recycling-Heroes - Multi-Input Field (Document)
In dieser Folge bringen wir weitere Komfortfunktionen in die Dokumenten App der Recycling-Heroes, kümmern uns um die verschiedenen Wertehilfen und aktivieren Multi-Input für die Tags auf der Object Page.
Inhaltsverzeichnis
In der heutigen Folge werden wir weiter an unserer Dokumenten-App arbeiten und zusätzliche Features und Komfortfunktionen implementieren. Damit kann der Anwender später einmal die App bedienen, weitere Dokumente hochladen und verschiedene Tags an einem Dokument pflegen, was relativ einfach funktionieren soll.
Readonly
Beim letzten Mal war es noch möglich, die Dokumenten-ID beim Anlegen zu pflegen. Dies benötigen wir nicht, da die ID automatisch als UUID erzeugt wird und das System die Verwaltung übernimmt. Dazu entfernen wir die Eigenschaft aus der Verhaltensdefinition und fügen den Zusatz am eigentlichen Feld oben an, damit das Feld die ganze Zeit read-only bleibt und wir keine Änderungen vornehmen können. In unserem Testfall legen wir nun ein neues Dokument an, geben dem Dokument eine Beschreibung, einen Langtext und einen Typen und hängen dann ein Dummy-Dokument an, um den Anlageprozess zu validieren. Der Prozess für neue Dokumente funktioniert nun und wir können uns den nächsten Annotationen widmen.
Annotationen
Dazu definieren wir in der Metadata Extension eine Annotation am Description-Feld. Hier aktivieren wir den Multi-Line Text. Damit ist eine Eingabe von längerem Text möglich, denn es wird eine größere Eingabe im UI generiert. Über True wird das neue Control aktiviert. Im zweiten Schritt definieren wir die eigentliche Assoziation auf die Tags. Diese benötigen wir, um das Multi-Input-Feld zu generieren. Danach definieren wir eine Annotation für die Identification, das heißt, das Feld taucht dann auf der Object Page auf. Neben der Position und der Zuordnung zur Facet definieren wir den Wert, der ausgegeben werden soll. Dabei gehen wir über die Assoziation und wählen das Feld der Tag-ID aus. Testen wir die Ausgabe im UI und gehen in den Edit Modus. Die Eingabe für die Beschreibung wird nun als Langtext angezeigt. Das Feld für die Tags ist zwar da und Eingabebereit, allerdings können wir hier noch keine Werte auswählen.
Dokumententypen
Daher müssen wir uns im ersten Schritt neue Wertehilfen für die bestehenden Objekte bauen, um diese dann in unser UI einbinden zu können. Fangen wir deshalb erst einmal mit einer Wertehilfe für den Dokumententyp an. In diesem Fall haben wir am Ende das falsche Template ausgewählt beziehungsweise der Standard war gesetzt und es wurde ein alter View generiert. Diesen müssen wir als Objekt nicht unbedingt löschen, sondern können relativ einfach ein neues Template wählen. Dazu entfernen wir den kompletten Inhalt des Codes und können dann über den Content Assist des Systems mit Strg + Leertaste die verschiedenen Templates aufrufen, die wir einfügen können. Hier wählen wir dann die View Entity, um das Template für die View Entity einzufügen. Wir übernehmen den Namen des Core Data Services ebenso wie die Entität, aus der wir lesen, und bereinigen den Header um einige Annotationen, die wir in dieser View nicht benötigen. Danach übernehmen wir alle Felder des zugrunde liegenden Core Data Services, um einen ersten Vorschlag zu erhalten, und aktivieren die Suche über die Annotation "searchable" im Core Data Service. Danach definieren wir an den verschiedenen Elementen, dass diese durchsuchbar sind, und über den Fuzziness Threshold setzen wir, wie die Fuzzy Search auf dieses Feld wirkt. Damit kann über ein Suchfeld dann auf beiden Feldern, nämlich dem Dokumententyp und der Beschreibung, gesucht werden. Weiterhin definieren wir das Textelement für den Dokumententyp, damit wir nicht nur den technischen Code sehen, sondern stattdessen zusätzlich den Text eingeblendet bekommen.
Tags
Im nächsten Schritt legen wir die Value Help für die verschiedenen Tags an. Dazu definieren wir wieder einen neuen Service direkt über dem definierten Core Data Service für die Tags. Um dir die Bearbeitung einfacher zu machen, legen wir beide Wertehilfen nebeneinander und können so die verschiedenen Annotationen für einen schnelleren Editier-Flow kopieren. Also übernehmen wir die Suchfunktion ebenso wie die verschiedenen Felder, die in der Suche auftauchen, und passen lediglich einzelne Elemente an, wo notwendig. Danach aktivieren wir den Core Data Service und haben auch diese Wertehilfe abgeschlossen.
Wertehilfen
Die neuen Wertehilfen können wir nun in unsere Dokumente übernehmen und fügen diese als Annotation auf Ebene des Core Data Service ein. Die Elemente müssen wir deshalb nicht noch einmal neu mappen, da diese bereits korrekt hinterlegt sind. Der Dokumententyp befindet sich auf der obersten Ebene der Root-Entität der Dokumente, dort fügen wir sie ein. Die Wertehilfe der Tags übernehmen wir dann in die darunterliegende Ebene, nämlich auf die Child-Entität der Dokumenten-Tags. Auch wenn das Element auf der obersten Ebene angezeigt wird, kommen das Feld und die Wertehilfe dennoch aus der Ebene darunter.
Testen wir nun einmal die Wertehilfen im UI. Diese werden nun hinter dem Feld gerendert. Für den Dokumententyp sehen wir alle vorhandenen Dokumententypen, die wir im System haben, und können dort einen auswählen. Bei den Tags können wir nun mehrere Tags aktivieren. Hier wird die UUID im Element eingefügt. Grundsätzlich sind über das Multi-Input-Feld mehrere Einträge möglich. Aktuell haben wir allerdings ein Problem, dass hier nicht die korrekten Texte angezeigt werden, sondern wir zum Beispiel nur die UUID im Feld sehen, was uns keinen echten Mehrwert bringt. Deshalb brechen wir das Speichern ab und wollen die Informationen in unseren Core Data Services anpassen.
Anpassungen
Dafür führen wir eine Anpassung in der Wertehilfe für den Dokumententyp durch. Hier möchten wir anstatt der Wertehilfe ein Dropdown haben, dies haben wir bereits in vorhergehenden Episoden durchgeführt. Dazu verwenden wir die Annotation "ObjectModel" und setzen hier die "Size Category" auf XS, was dann wiederum im UI eine Dropdown-Liste generiert. Als Nächstes wollen wir auf die fehlenden Texte im UI eingehen, darum navigieren wir auf die unterste Ebene unseres RAP-Objekts für die Tags und fügen die Assoziation zur Wertehilfe hinzu. Über die Wertehilfe können wir ebenfalls die Texte ermitteln, die zum Beispiel für dieses Tag benötigt werden. Haben wir den Core Data Service per Assoziation eingebunden, können wir dann wiederum auf die Consumption View wechseln und dort das Description-Feld mit einbinden. Dadurch befindet es sich in der Entität, wird aber zum Beispiel nicht im Draft gespeichert, was es auch nicht muss. Als Nächstes können wir dann das Text-Arrangement einfügen und definieren, dass wir hier nur den Text sehen wollen. Damit blenden wir die UUID aus und definieren dann das Textelement, welches wir lokal angelegt haben. So bekommen wir am Ende die verschiedenen Tags als Texte angezeigt. Testen wir nun alle Änderungen im UI und ändern dazu den Dokumententyp einmal auf ein Autobild, passen den Titel an und wählen dann aus den entsprechenden Tags noch einmal passende Tags für unser Dokument. Bereits bei der Auswahl sehen wir, dass im unteren Teil nicht mehr die UUIDs angezeigt werden, sondern direkt die Texte geladen werden, was es anschaulicher macht. Beim Speichern der Entität werden dann noch die Texte angezeigt; der Punkt dazwischen bedeutet, dass wir hier zwei Einträge innerhalb des Feldes haben.
Die gleiche Anpassung können wir nun für die Dokumententypen durchführen, indem wir auf der Root-Ebene den entsprechenden Eintrag für einen Dokumententyp aufnehmen und dann den Text für einen Dokumententyp in die Consumption View einbinden. Dazu ergänzen wir dann weitere Eigenschaften, dass zum Beispiel der Text als erstes angezeigt werden sollte und der technische Wert dahinter, und binden den Text dann an den eigentlichen Dokumententyp. Da es sich hier um die identischen Schritte handelt wie vorher, zeigen wir das in diesem Video nicht, gucken wir uns aber zumindest das Ergebnis am Ende im UI an. Der Datensatz zeigt nun im Dokumententyp den eigentlichen Text vorne und hinten den technischen Wert, der auf der Datenbank abgelegt wird. In einem produktiven UI interessieren die technischen Werte meistens den Fachbereich nicht. Hier sollte dann am Ende nur der eigentliche Text hinterlegt sein.
Zusammenfassung
In der heutigen Folge ging es vor allem darum, wie wir ein Multi-Input-Feld in unserer Entität enablen können, um mehrere Werte in einem Feld zu hinterlegen, obwohl diese Informationen aus einer Child-Entität kommen. Zudem haben wir verschiedene Annotationen verwendet, um Wertehilfen bereitzustellen und ein Langtextfeld für unseren Text zu erzeugen. Damit sieht die App schon viel freundlicher und benutzbarer aus und wir können uns beim nächsten Mal vor allem auf das Thema Daten fokussieren. Von daher danke fürs Zuschauen und bis zum nächsten Mal!
YouTube
Video