Hmm...
Du willst nicht die Katze im Sack kaufen, und mehr über das Universal-Frontend wissen ?
Verstehe...
Am besten liste ich Dir erstmal die Features bzw. Vorteile gegenüber den üblichen Office-Datenbankanwendungen auf.
- Ausgefeilter Standardfilter,
in jedem Formularfeld können komplexe Filterbedingungen eingegeben werden - beliebig viele Unterformulare,
mit beliebiger Verschachtelungstiefe,also Unter-Unter...Formulare möglich - ansprechendes Autolayout, generisches Formular
- flexibles Design von Formularen und Toolbars
- Formulare, Widget-Eigenschaften und Events transparent über Datenbank-Tabellen gesteuert
- unterschiedliche Arbeitsmodi
der Formulare für Suchen, Anzeigen, Ändern und Hinzufügen von Datensätzen - Unterstützung von User-Rechten *
- Unterstützung von Änderungen im Tabellenmodell*
Und...? Läuft dir schon das Wasser im Mund zusammen ?
Du weißt ja, wo Du die Download-Seite findest.
...
...
...
Was... ? Du bist immer noch hier ?
Du willst dich nicht mit ein paar hingerotzten Schlagwörtern abspeisen lassen ?
Ok, lass mich die oben aufgeführten Punkte näher erläutern.
- ausgefeilter Standardfilter
Mit Standardfilter ist gemeint, dass man das Eingabeformular einer Tabelle, ebenfalls verwendet, um Daten aus dieser Tabelle abzufragen. Die Officeprodukte machen aber grundsätzlich eine Eingabeprüfung direkt bei der Dateneingabe in einem Feld, auch wenn man das Formular zur Abfrage verwendet. Damit wird die Eingabe von Vergleichsoperatoren verunmöglicht, z.B. ist <100 keine erlaubte Eingabe in einem numerischen Feld. Somit wird die Abfrage auf Exact-Match eingeschränkt, wodurch der Standardfilter in Office-Produkten nahezu unbrauchbar wird.
Universal-Frontend macht erstens die Eingabeprüfung sowieso später, und zweitens im Abfragemodus natürlich eine andere Prüfung. Es können die üblichen Vergleichsoperatoren eingegeben werden, für Pattern-Match bei Strings existiert ein eigener Operator. In jedem Feld können mehrere Bedingungen durch und/oder Verknüpft werden. Natürlich können in beliebig vielen Feldern Filter-Ausdrücke eingegeben werden. Die logische Verknüpfung ist dann und . Auch in Feldern von Unterformularen können Filter-Ausdrücke eingegeben werden. - beliebig viele Unterformulare
Dies ist das wichtigste Feature um das Frontend richtig, richtig mächtig zu machen. Wieso erlauben die Office-Produkte nur ein Unterformular ? Das ist sowas von lahm.
Unterformulare dürfen natürlich auch weitere Unterformulare enthalten, das sie rekursiv abgearbeitet werden. Es können also sehr komplexe Formulare schnell und einfach entworfen werden. -
ansprechendes Autolayout
Was ist das eigentlich für ein Rotz, den die Officeprodukte raushauen, wenn man ein Formular mit dem Formularassistenten automatisch generieren läßt, und eine Anordnung der Widgets in Blöcken haben will. Wird die Größe der Widgets ausgewürfelt ? Ich kann da keinen Zusammenhang zur Größe des korrespondierenden Tabellenfeldes erkennen. Das Layout muss immer noch manuell nachbearbeitet werden.
Das Universal-Frontend generiert die Widgets in der Reihenfolge, wie die Felder in der Datenbank definiert sind. Die Größe der Widgets ist passend zur Größe der Tabellenfelder. Auch ohne Nachbearbeitung ist das Formular gut benutzbar.
Dies wiederum erlaubt die Erstellung eines generischen Formulars( mit Block-Anordnung wohlgemerkt !) bei dem man die Tabelle auswählt, und just in time die Eingabe-Widgets erzeugt bekommt. Das generische Formular in den Office-Anwendungen hingegen ist einfach ein Tabellen-Widget.
Nebenbei bemerkt: Universal-Frontend erzeugt immer die drei Ansichtsarten Blöcke, Tabelle, Liste. -
flexibles Design von Formularen und Toolbars.
Toolbars sind technisch gesehen auch nur Formulare, die allerdings nicht an eine Tabelle gebunden sind. Es können beliebig viele Toolbars entworfen und in ein Formular integriert werden. Jedes Datenbankformular wiederum kann auch als Unterformular verwendet werden. Dadurch wird (hoffentlich) jede Designidee unterstützt. -
Alles wird transparent über Datenbanktabellen gesteuert
Es wird das Datenbankschema Frontend erzeugt mit allen notwendigen Tabellen, die für die Ablaufsteuerung der Formulare notwendig sind.
Die Tabelle Widget enthält wichtige Widgeteigenschaften, wie z.B. Datenquelle für die Einträge einer List- oder Combobox, Eingabeprüfung, Stylesheet und anderes.
Die Tabelle Form enthält die Zuordnung zu einer Datenbanktabelle, inkl. der Verbindung zu einem (evtl. entfernten) Datenbankserver. Weiterhin die Formularresource und ebenfalls ein Stylesheet-Feld.
In der Tabelle Event können Ereignisse behandelt werden, wenn sich z.B. der Wert eines Feldes ändert oder ein Button angeklickt wird. Den Ereignissen können eine Vielzahl von Aktionen zugeordnet werden. Aus Sicherheitsgründen möchte ich hier keine vollwertige Programmiersprache andocken.
Falls jemand jetzt sagt: "Moment mal. Du hast uns doch keinerlei Programmieraufwand vesprochen, Du Lügner !"
Dann muss ich zugeben: Ja, stimmt. Das war eine didaktische Vereinfachung. Genauer muss es heißen: Der Programmieraufwand wurde auf das allernotwendigste reduziert. Und das ist eben die Behandlung der für das Formular charakteristischen Ereignisse. Z.B. bei einen Bestellformular: gib eine Fehlermeldung aus oder ignoriere eine Bestellzeile, wenn der Artikel ausverkauft ist. In der Regel ist der Aufwand so gering(1-5 Zeilen pro Ereignis), dass man kaum von Programmieren reden kann. -
Unterschiedliche Arbeitsmodi für Suchen, Anzeigen, Ändern und Einfügen von Datensätzen.
Und auch hier muss ich die Office-Produkte kritisieren. Dadurch, dass sie nur einen Eingabemodus für alles verwenden haben sie sich als Profi-Anwendung disqualifiziert . Ok, man kann zwar dort in den Formulareigenschaften einstellen, was erlaubt ist, aber kann man das auch zur Laufzeit umschalten, oder muss ich für jeden Modus ein eigenes Formular erstellen ? Die Widgets können auch nicht ohne Programmieraufwand abhängig vom Modus aktiv, inaktiv, sichtbar oder unsichtbar gemacht werden. Dies sind aber alles Voraussetzungen für den nächsten Punkt: -
Unterstützung von User-Rechten:
Es ist mir ja ein bisschen peinlich, dass dieser Punkt noch nicht implementiert ist, aber es ist auch kein Beinbruch. Die User-Rechte werden ja vom Datenbank-Server verwaltet. Das Universal-Frontend ist z.Zt. noch nicht in der Lage die Rechte abzufragen und angemessen zu reflektieren indem Formulare oder Widgets gesperrt oder versteckt werden. Das kann zu unnötigen serverseitigen Fehlermeldungen führen, falls man Dinge tun will die man nicht darf. -
Unterstützung von Änderungen im Tabellenmodell:
Dies wird das absolut wertvollste Feature. Endlich wird es möglich sein, das Datenbankmodell an organisatorische Änderungen in einem Unternehmen anzupassen. Da die Formulare und Widgets transparent über Tabellen verwaltet werden ist es zumindest möglich, durch geeignete Datenbankabfragen eine ToDo-Liste zu erstellen, über die notwendigen Formular-Anpassungen, falls eine Tabelle abgeändert wurde. Sowohl Hinzufügen Ändern und Löschen von Tabellenfeldern als auch das Zerlegen einer Tabelle(falls man eine 1:n-Relation übersehen hat) sollte problemlos möglich sein.