Das Folgende ist ein Mix aus Erfahrungsbericht eines Filemaker-Umsteigers und Frageliste zur Kontrolle über das User Interface und zu Funktionen.

Vorwort: Die Hälfte ist vielleicht "Opa gegen Vue.js". Das kann ich aber nicht genau beurteilen. Ich meine nur, daß manche Beschwerden an Vue.js weiterzuleiten wären. Mein psychologischer Hintergrund ist der, daß ich mit wenig Aufwand ein schlichtes User Interface haben möchte, ohne von irgendwelchen Menschen, die das Internet neu erfinden, mit deren Geschmack belästigt zu werden. Also das vorab als meinen Bias, den ich einfach offen legen muß.

Die Datendefinition hat super funktioniert. Die Verknüpfung der Formulare nach einem gewissen Lernaufwand auch. Zur Weißglut bringt mich nur die Darstellung.

Datenstruktur

Ich habe ein Minimal Working Example erstellt, bestehend aus Artikel, Verpackungseinheit und Preis, wobei Preis natürlich eine M:N-Relation auf die ersten beiden ist mit dem Preis als Attribut.

Der Preis ist numeric. Zu Vergleichszwecken habe ich in zwei Anläufen zwei numeric(8,2) Werte in Artikel definiert. Verwirrend war dabei, daß die Nachkommastellen als 0 angezeigt werden, wenn man im Builder die Eigenschaften eines zuvor definierten Attributs aufruft. Das hat das zweite numeric verursacht. In Postgres waren aber beide Werte gleich korrekt mit numeric(8,2) angelegt.

Aufgabenstellung

Es soll die Artikelliste angezeigt werden, mit den coolen Filteroptionen, die ein echtes Argument pro REI3 sind.

Wenn man darauf klickt, erscheinen die Daten des Artikels oben und darunter die Preise dieses Artikels. Das entspricht dem vom Filemaker her gewohnten.

Daß man nicht direkt in dieser Liste den Preis ändern kann, habe ich verstanden. Das ist eine Umstellung, die eben notwendig ist. Dafür ist klarer, wann gespeichert wird, was auch Vorteile hat.

Beim Klicken auf eine Zeile auf der Preisliste erscheint also ein Formular, auf dem ich Verpackungseinheit und Preis ändern kann. So weit, so kommunizierbar.

Darstellungsproblem Nachkommastellen

Ich kann keine Möglichkeit finden, in den Felderdefinitionen im Formular die Anzahl der Nachkommastellen anzugeben. Oder Zentrierung am Komma, was noch besser wäre. Aber auch daß die Nullen verloren gehen, ist in der Finanzabteilung inakzeptabel. Aus 9,70 in einem numeric(8,2) werden unweigerlich 9,7 in der Darstellung. Man sieht es auch bei der Eingabe, daß die Null am Ende sofort von irgendeiner Javascript-Funktion im Hintergrund entfernt wird.

In der Dokumentation oder in Release Notes steht wird die rechtsbündige Darstellung für Zahlen mit Nachkommastellen empfohlen, aber ich schaffe es nicht, diese Nullen zu bekommen, ohne die rechtsbündig genauso dumm ist wie linksbündig.

In der Musteranwendung Zeiterfassung werden die Stunden mit Nachkommastellen linksbündig dargestellt, was in diesem Fall gut aussieht, weil es immer eine Vorkommastelle gibt. Aber das hilft mir in meiner Preisliste nicht weiter.

Klargestellt werden muß, daß es ausschließlich um Listen geht. Im Formular für die interaktive Eingabe ist das kein Thema, daß 9.7 dort steht. (Also der Punkt schon, aber ok. Jedenfalls geht die Null am Ende hier niemand ab.) Aber bei einer Zahlenkolonne brauche ich eine professionelle Darstellung, sonst ist es einfach unleserlich.

Darstellungsproblem Spaltenbreite

Damit die Artikelliste nicht so grotesk über die ganze Breite verteilt wird, habe ich sie in einen Container gesteckt. Bis auf die Sache mit den Zahlen sieht sie nett aus. (Linksbündig statt mittig wäre eine gleichwertige Gestaltungsmöglichkeit. Wichtig ist nur, daß nicht hunderte Pixel zwischen Artikelcode und Artikelname stehen und Name eine eigene Fluchtlinie hat, also nicht im selben Batch mit Code steckt.)

Aber nach dem Anklicken einer Zeile wird der rechte Teil verdeckt, völlig grundlos. Als "Max. Breite (px)" habe ich 1500 hinterlegt. Der Container, in dem die Liste steckt, hat Startgröße automatisch, Wachsfaktor 5 und Schrumpffaktor 0. (Und Inhalte umbrechen ist false.) Auch Wachsfaktor 100 ändert nichts daran.

Die ganze zur Verfügung stehende Breite (mit dem Circuits-Hintergrund) ist 1330 px, aber nur 1001 px werden für den Container mit der Artikelliste genutzt. Niemand weiß, warum. Und das ist es, was mich als Designer und Programmierer ärgert.

Das Subformular (mit eingestellter maximalere Breite 1500) hat lt. Firefox Inspector eine Breite von knapp 780, wobei er sagt, daß die Basisbreite dieselben 1001,37 vom Gesamtcontainer wären und durch Schrumpffaktor 1 221 px davon weggenommen werden. Dieser Schrumpffaktor steckt in div.form-wrap.popUp.inline. Kann man darauf zugreifen, wenn man die Profi-Version lizensiert? Aber selbst wenn ja, dann müßte man diesen Faktor händisch anpassen an die Inhalte, die man links nicht verdecken will.

Wenn ich bei dem Container, der die Liste mit Verpackungseinheit und Preis enthält, Align items flex-start statt stretch wähle, dann wird das Subformular schmäler, auch gut 500 px, aber die verdeckte Spalte der Artikelliste erscheint mitnichten. Und diese beiden Spalten lassen wenig attraktiv rechts ungenutzten Raum frei, was natürlich die Bedeutung von flex-start ist.

Es geht auch gar nicht so sehr um das Schrumpfen, sondern um dieses mutwillige verdecken des Hauptformulars durch das Subformular.

Ich befürchte fast, daß das von irgendeinem Designer so geplant ist und das Abschaffen dieses Zustandes daher ein Feature Request ist. (Beim Erstellen des Screenshots zeigt sich ein kleiner Scrollbar unten am Ende der teilweise verdeckten Artikelliste. Das verstärkt meine Befürchtungen, und ich sehe keine Chance, hier einzugreifen.)

Integration von Frontend-Formeln

Die Sache mit den Nachkommastellen hat mich natürlich dazu gebracht, über die Formeln nachzudenken. Aber ich habe keine Ahnung, wie man Formelergebnisse in Formulare einbauen kann. Irgendwie sehe ich da nur Schweigen, aber wahrscheinlich bin ich wieder blind.

Intuitiv fände ich:

function zahl_formatieren(x) {
	return x.toLocaleString('de-DE', { minimumFractionDigits: 2 });
}

Daß ich in das Textfeld der Funktion nur den Body schreiben darf und das Argument x in das Formularfeld für die Argumente (in Tab Eigenschaften), das ist schon klar.

Aber wenn ich jetzt eine Formel an ein Formular anbinde, dann muß das das mit der Liste sein. Das hat keine Relation 0. app.get_record_id(0) liefert -1, was verständlich ist. Und es gibt keine Platzhalter.

In einem normalen Formular, das nur einen Datensatz anzeigt, da habe ich das hingekriegt:

var x = app.get_field_value({F9: 0 artikel.numeric2}).toLocaleString('de-DE', { minimumFractionDigits: 2 });
console.log(x);
app.set_variable({test.Artikel Eingabe.zahl_mit_null}, x);

Zu dumm, daß man einen Ort suchen muß, an dem das Feld der Variable von vorne herein groß genug ist. Wenn es auf der Zeile neben den Zahlen steht, dann bekommt es zuerst Nutzbreite Null, was zuerst ok ist, und wenn es die Variable dann einen Wert zugewiesen bekommt, dann merkt es keiner. Oder ich weiß noch nicht, welche refresh/redraw-Funktion ich aufrufen muß, damit Vue die Sache noch einmal reevaluiert. Im Gegensatz zu normalen Datenfeldern gibt es auch keine Mindestbreite in Pixel, die man hinterlegen könnte.

Was wirklich dumm ist, das ist, daß ich jetzt eine Lösung für den Fall habe, wo es halb so schlimm ist, nämlich bei der Einzeldatensatzanzeige. Und bei der Liste, wo das mit der Fluchtlinie das große Thema ist, da kann man diese Lösung nicht anwenden.

Lösungsansätze im Backend

Es liegt auf der Hand, daß es REI3 sehr recht wäre, wenn der Preis als Text in der Relation zu finden wäre. Aber bei der Vorstellung, alle Zahlen, die ich formatiert haben möchte, redundant als Text zu speichern, überkommt mich eher zuviel an Brechreiz.

Auch eine extra Zugriffsfunktion pro Relation mit numeric, oder eine pro numeric Column, wäre mäßig witzig.

Wenn es denn Backend sein muß, dann hätte Postgres das Feature der Generated Columns, aber leider nur in der gespeicherten Version, nicht virtual, was meine Präferenz wäre. Die werden ziemlich sicher nicht von REI3 unterstützt. Wenn ich sie hineindoktorn würde, bei angehaltenem REI3-Server, mittels INSERT in app.attribute und
ALTER TABLE test.preis ADD COLUMN preis_text GENERATED ALWAYS AS (to_char(preis, '9G990D00'));
dann wäre das automatisierbar. D.h. ich könnte immer wieder abfragen, welche numeric Columns noch keine Column mit _text daneben haben. Aber das redundante Speichern mag ich sowieso nicht.

Aber es wäre definitiv nicht elegant.

Zusammenfassung

Bei den Nachkommastellen kann ich nur hoffen, daß ich blöd oder/und blind bin. Dann war mein Ausflug in die Welt der Funktionen eine Lerneinheit, die mir sowieso nicht erspart bleibt.

Bei der Sache mit der Überlappung bzw. dem unberechenbaren/unbeeinflußbaren Layout kann ich auch auf Ganze Seite statt Subformular ausweichen. Aber vom Platz her wäre es nicht notwendig. Bei der Einzelpreisbearbeitung kommt Ganze Seite nicht in Frage, weil es das genau so gemeint ist und alle andere wegräumt.

Vielleicht ist es auch ein Feature Request, auf den es sich hinausläuft, nämlich ein Subformular, das nicht von rechts, sondern von unten reingeschoben wird. Aber das Grundproblem ist, daß hier zwar viel von Flex Layout die Rede ist, nachher aber erst recht wieder irgendein Geheimrezept aus der Vue.js-Küche (oder der REI3-Küche) gekocht wird.

Genau genommen habe ich mir vorgestellt, daß dieses Subform seitlich neben der - nach Flex-Layout-Regeln - zusammengestauchten Liste erscheint. Das beschreibt vermutlich in einem Satz das ganze Problem.

Wenn man diesen Lösungsansatz weiterdenkt, dann kommt man zu einem zweispaltigen Layout, wo der größere rechte Teil durch Anklicken von Listeneinträgen links befüllt wird. Dazu müßte man aber die Zeilen dieser Liste umprogrammieren, sodaß sie die ursprüngliche Funktionalität verlieren und nur mehr app.form_open aufrufen. Wenn man aber einfach Buttons untereinander anordnet, dann verliert man die tabellarische Darstellung. Außerdem muß man natürlich einigen Code schreiben, um die record_id zu bekommen und die form_id muß man (unelegant) aus der Datenbank.

"Spannendes Projekt" haben wir beide gleich am Anfang gesagt, aber so aufregend/nervenaufreibend hätte gar nicht sein müssen.