Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- elo:vergleich_gen1_gen2 [2026/01/11 11:56] – [Zukunftssicherheit] 128.204.144.132
+++ elo:vergleich_gen1_gen2 [2026/02/27 18:47] (aktuell) – 217.9.109.34
@@ Zeile 16: / Zeile 16: @@
 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.
+===== Machbarkeit und Endurance von Entwicklern =====
+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.
 ===== Lokalisierbarkeit von Formularen =====