Dieser Artikel vergleicht hier Generation 1/2 ganz grundlegend in unterschiedlichen Vergleichsdisziplinen.

In Sachen Customizbarkeit hat hier die Generation 1 Formularwelt die Nase vorne. Individuelle Formularblöcke sowie freier Zugriff auf das DOM/BOM ermöglichen hier alle Varianten von Ausgestaltungen. Bei Generation 2 müsste man das System schon gewissermaßen mit Filter-Injection jailbreaken, um hier die selben Freiheiten zu erlangen. Eher möglich, aber definitiv nicht unbedingt gewünscht ist eine solche Vorgehensweise. Bei Generation 2 ist hier vieles einfach vorgegeben, mit Version 25 wird das Korsett deutlich enger, in denen man eigene Lösungen entwickeln kann, da hier der Zugriff auf das DOM/BOM maskiert und unterbunden wird. Eigene Stylesheets sind hier nicht möglich, eigene Komponentenentwicklung auf Vue.js Basis ebenfalls nicht. Wohl hier für die „verspielten“ Business Partner das Hauptproblem in diese Schiene zu wechseln.

Hier hat wiederum die Generation 2 seinen Vorteil. Während Generation 1 Formulare nicht in der Postbox verwendet werden können und somit wiederum auf die alte „Ablagemaskenlogik“ zurückgegriffen werden müsste (außer man baut sich hier wirklich mit erheblichem Aufwand ein „Bett“ für die Verwendung von Generation 1 Formularen in der Postbox), kann hier Generation 2 wirklich durchgängig bei unterschiedlichen Ablageszenarien verwendet werden. Somit kann die Vielfalt der „ELO Clients“ abgedeckt werden.

• JavaClient: keine Anpassungen mehr mittels IndexDialogAdapter JavaScript notwendig
• WebClient: keine Anpassungen mehr mittels WebClient Scripting
• DesktopClient: Ablagen können hier auch ohne vorherige Definition von ActionDefinitions passieren
• IntegrationClient: ?

Summa summarum also ist hier eine durchgängigere und einfachere Vorgangsweise möglich als bei Generation 2. Die Komplexität sinkt hier drastisch. Zum Abbilden von Postbox-Massenablagen ist hier im JavaClient ein einfaches Skript notwendig, dass hier die Ablagen automatisiert durchführt. Seit Version 25 ist das aber kein Problem mehr, da der JavaClient hier auch richtig per Scripting auf die Ablagen reagiert.

Generation 2 ist im Vergleich zu Generation 1 also auf den ersten Blick einmal leichtgewichtigere Kost. Die Frage ist hier für Business-Partner immer, wird sich hier der Consultant an diese Technologien binden? Entsteht so wie bei Generation 1 wieder ein Drehtüreneffekt? Das ist eher schwierig zu sagen. Obwohl ELO die Low-Code Bubble schon bereits 2019 betreten hat, blieb hier der Fame natürlich wieder einmal aus. Während SharePoint jeder kennt, DocuWare schon viel mehr als ELO entsteht bei Neulernenden immer sofort die Frage, wie oft ist das Tool im Einsatz, lohnt es sich. Bei arrivierten Developern verhält es sich ein wenig anders. Hat man sehr hohe Scripting Anteile in der Architektur, dann kann die Systematik mit Struktur und Richtlinien bestechen. Ansonsten kann die Modularisierung bestehende Entwickler ansprechen. Spricht man mit Admins über Low-Code / No-Code so werden Namen wie SmapOne oder Ninox viel früher fallen als ELO. Ebenso n8n. Von irgendwelche KI-Frameworks, Tools und Gadgets die hier durch den Äther krebsen reden wir erst einmal nicht. Somit hatte Generation 1 einen hohen Drehtüreneffekt und zwar ein beide Richtungen. Es förderte Kurzzeitentwickler und Cherry Picking Entwickler.

Schulungen sind mittlerweile auch für Scripting in Generation 2 verfügbar. Gesamt also weniger individuelle Programmiermöglichkeiten und weniger „Overkill-Customizing“, das hier in Programmier/Anpassungsstunden mündet. Hier muss man dazu sagen, dass vor allem Generation 1 prädestiniert dafür gewesen ist Katastrophen zu verursachen. Schnell mal das Feld aufgemacht (Read-Only entfernt) oder einfach mal gelöscht, auf den ersten Blick sah es ja eh gut aus. Dann noch schnell das Feld von 4 Nachkommastellen auf 2 gekürzt. Auf den zweiten Blick ging dann die Formular in gewissen Punkten nicht mehr, die Berechnungen waren möglicherweise falsch (man wusste natürlich ohne Testsystem im originalen Auslieferzustand mit selbigen Versionen nicht, ob das wirklich so war). Das Unangenehme bei Generation 1 war hier teilweise immer die Verkettung der Events und die Unbeweglichkeit der Skript-Funktionen sowie einfach die fehlenden Codeguidelines und die klar Vorgangsweise beim Überschreiben von Funktionen.

Alles in allem war die Generation 1 für uns vor allem eins. Gutes Marketing und wenig Substanz. Bei Generation 2 fallen aufgrund der einfachen Transportierbarkeit viele Dinge nicht so sehr ins Gewicht. Der Frustrationslevel, der sich hier bei Entwicklern aufbaut ist hier möglicherweise nicht so hoch. Andererseits ist es natürlich mit Flows dann wiederum so. Es ist natürlich Prozessautomatisierung im Nischenbereich. Entweder mit ELO oder ohne ELO ist hier die Devise. Warum also diese Technologie lernen, wenn man als Business-Partner immer eine „Heerschar“ an Consultants braucht? Für viele ist der Benefit nicht so ersichtlich. Für mich eher auch nur deshalb sinnvoll aufgrund der vielen Kontakte im ELO Bereich und dem „Spass am Spiel“. Andere Gamen gerne, ich arbeite mich halt gerne an Technologien ab.

Hier gewinnt ebenfalls die Generation 2 ggü. der Generation 1. Lokalisierungen können mittels Lokalisierungstabelle im Paketdesigner der AdminConsole erfolgen. Hier können auch mehrere Sprachen gleichzeitig lokalisiert werden. Je nach Einstieg in die AdminConsole (hier ist die Einstiegssprache entscheidend), kann hier zwischen 20 verschiedenen Sprachen gesprungen werden. Ein Bearbeiten von verschiedenen Sprachdateien ist ebenso wenig notwendig wie ein mühsamer Reload des WF, der in bestimmten Cloud Umgebungen (und rein generell auch bei großen Systemumgebungen) administrativen Eingriff notwendig machen würde. Externes Lokalisieren mittels Export der Tabelle, Bearbeitung und Import der Tabelle ist ebenfalls möglich, wobei hier die grafische Schönheit des ganzen Prozesses entfällt. Eine Verbesserungsmöglichkeit wäre hier noch das automatische Aufräumen der Tabelle bei überschüssigen Einträgen.

Hier gewinnt wenig überraschend ebenfalls Generation 2. Bei Generation 1 wird es hier wieder ein ähnlicher Prozess werden wie beim Bruch Windows/JavaClient. Zuerst wird eine gewisse Skepsis da sein wie bestimmte Projekte mit Generation 2 ins Laufen kommen. Der Hersteller wird dann über Jahre hinweg immer irgendwie und ohne echte Vision für den Partner an dieser und jener Ecke nachbessern. Die Koryphäen und Entwicklungsalphas werden dann zügig auf das Generation 2 Schiff überspringen bei neuen Projekten. Die Betas werden dann diesen Projekt wieder nachhüpfen. Und nachdem ja Generation 2 ja eh schon seit 2019 irgendwie immer da war, wird der Hersteller wahrscheinlich so um 2029/2030 rum sagen: trari, trara die Generation 1 ist jetzt baba. So war es auch beim Win/JavaClient Thema. 2006 die erste Version, bis 2013 kaum brauchbar und ab 2016 ging hier die Info rum, dass das jetzt die letzte Windows-Client Release sein wird, die mit Version 10 kommen wird. Der große Nachteil von der Philosophie ist halt immer, dass bis zu diesem Zeitpunkt dann die Karawane schon wieder längst weitergezogen sein wird, die Entwickler die Generation 1 am Leben halten, werden hier schon wahrscheinlich 2027/2028 schon längst vollständig übergesprungen sein. So ist es eigentlich auch 2018 bereits bei einem Großkunden mit dem Windows-Client gewesen. In ganz Österreich gab es hier eigentlich nur mehr 2 Experten mit Windows-Client Erfahrung. Definitiv zu wenig, um den Markt zu bereinigen. Es geistern hier immer noch Gerüchte um eine Handvoll Partner, die hier immer noch Windows-Clients im Einsatz haben sollen.