roma() - AutoIt Framework (benötige Unterstützug)

  • Hallo zusammen,

    lange habe ich hier nichts mehr gepostet, jedoch sehr sehr viel mitgelesen.

    Vorwort
    Ich arbeite bereits seit längerem an einem AutoIt MVC Framework, was die Entwicklung mit AutoIt komplett umkrempelen soll. Ich weiß ich weiß den einen oder anderen wird das überhaupt nicht schmecken, ich mag es jedoch um so mehr.
    Ich habe mich sehr stark vom PHP Framework (Laravel) insperieren lassen und daher roma() ähnlich aufgebaut.

    Ziel

    • Hauptziel dieses Frameworks ist es GUI's mit HTML, CSS & Javascript erstellen zu können und am besten diese auch Live zu gestalten.
      Das ganze funktioniert mit 2 Schichten.
      - Fontend = HTML,CSS & Javascript
      - Backend = AutoIt
    • MVC Entwicklung mit AutoIt
    • Bessere und modernere UDF Verwaltung

    Unterstützung
    Ich habe leider nicht mehr viel Zeit für das Projekt, da ich zum zweiten Mal Nachwuchs bekommen habe und nun ein Job Wechsel bevorsteht, wo ich mich intensiv mit Javascript auseinander setzen muss. Daher dachte ich mir bevor das Projekt verstaubt und niemals das Licht der Welt erblickt, teile ich es und bitte euch um Unterstützung um dieses Projekt fertigzustellen und weiterzuentwickeln.

    -----------------------------------------------------------------------------------------

    Das Framework ist steht für alle kostenfrei zur Verfügung.
    Lizenz: MIT Lizenz

    GitHub: https://github.com/4ern/roma


    Todos:
    - Loop Funktion in Template.au3
    - Packagemanagment System (ähnlich wie npm).
    - CLI Modul
    - Lösungsansätze, wie das Framework optimal compiliert werden kann (evtl. ein eigenen Wrapper?)
    - Umfangreiche Tests

    Weiteres
    Braucht Ihr mehr Infos? Dann sagt mir was ihr genau wissen wollt, ich werde mich bemühen alles zu erklären.
    Das Framework selber habe ich versucht sogut es geht zu dokumentieren, schaut es einfach an.

    Testen:
    Das Framework könnt Ihr testen, indem Ihr einfach die application.au3 ausführt.

    ---

    Edit: Dokumentation auf gitHub verschoben, da ich das ganze somit doppelt pflegen muss.

  • Hallo zusammen,

    schade dass das Projekt nicht so gut angekommen ist. Vermutlich liegt das an der fehlenden Dokumentation.
    Ich werde hier die Dokumentation in laufe der Zeit vervollständigen.

    Vielleicht wird irgendwann dem ein oder anderen das Framework was nutzen.

    Ich würde mich auch über etwas Feedback freuen.

    Danke

  • Ok, dann geb ich mal Feedback. Ich verstehe den nutzen des Framework nicht wirklich. Im Grunde machst einen Autoitwebserver und arbeitest die eingehende URL aufrufe ab. Dazu gibt es mittlerweile sehr viele Beispiele im Web. Kannst du mal genau erklären was dein Framework jetzt so besonders erleichtert?

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

  • Hey @chip vielen Dank für dein Feedback.

    Ja ich weis etwas zu erklären ist nicht wirklich meine stärke :).
    Ich nutze AutoIt schon länger nicht mehr zum purem automatisieren von Anwendungen, sodern nutze es um komplexe eigenständige Anwendungen zu entwickeln. Da AutoIt so ziemlich alles bietet, was man dafür braucht.

    Mich hatt es sehr gestört, dass man in AutoIt sehr schwer die Logik von der Präsentation trennen kann und zudem die standart GUI elememte sehr unflexibel sind. Will man etwas anspruchvolleres muss man sich mit GDI rum schlagen wo man für einen simpelenn runden Button schon zig Zeilen Code schreiben muss.

    Daher habe ich mich nach alternativen umgeschaut und leider nichts gefunden, wo ich zufrieden war. Daher habe ich mir selber eine Lösung überlegt, wie ich die Logik von der Präsentation trennen kann und zudem HTML und CSS in meiner GUI nutzen kann. Daher enstand die Idee zu diesem Framework.

    Die erste große Hürde bestand darin mit AutoIt auf die HTML Seiten zuzugreifen. Ich hatte da viele Ansätze, die einzigste Lösung, die gut funktionierte und alle Elemete von HTML berücksichtigte, war der transport der Daten über den http Protokoll. Daher habe ich einen minimalen http Server gebaut.

    Der http Server ist zwar ein wichtiges Bestandteil des Frameworks. Ist aber eigentlich nur eine Art Brücke zwischen AutoIt und HTML.

    Das Framework dient in erster Linie zur Entwicklung von eigenständigen Applikationen.
    Erleichterungen:

    • Alle notwendigen Settings sind vorkonfiguriert, man kann sofort mit der Logik oder der View beginnen.
    • Alle Settings sind an einem Ort.
    • Die Logik(controller) und die Presentation(View) sind klar von einander getrennt.
    • Entwicklung mit MVC Struktur
    • Man kann die GUI in realTimer entwickeln, ohne AutoIt ständig neu starten.
    • GUI können in HTML entwicklet werden.
    • Jede möglich Grafik & Video einbindung möglich (.png, .gif usw.) alles was halt in HTML5 & CSS3 möglich ist.
    • JavaScript wird unterstützt.
    • Debug Logs werden ersellt inkl. Consolen Ausgabe.
    • Das Framework ist Multinationa. (Also die Anwendung kann in mehreren Sprachen ausgegben werden)
    • Alle udfs sind im Framework enthalten, kein evtl. nachladen nötig.
    • Das Framework bietet auch viele Funktionen, die für die komminiktaion zwischen AutoIt und HTML notwendig sind. Z.b Auswertung von Formular Daten usw. Dokumentation hierfür und Beispiele folgen noch.
    • Ich habe zu dem ein Template Engine entwickelt. (Ähnlich wie Laravel Blade)

    Beispiel:

    HTML
    <html>
      <head>
        <title>Template Test</title>
      </head>
    
      <body>
        <h1>Mein Name ist {{ $vorname }} {{ $name }}</h1>
      </body>
    </html>
    • das Template System unterstützt auch If Statements. (hätte gerne Hilfe um auch Schleifen zuermöglichen.)
      Eine komplette Dokumentation des Template Systems und Beispielen werde ich noch veröffentlichen.
    • Fast fertig ist ein Datenbank Package. Damit wird die kommunikation mit Datenbanken ein absolutes Kinderspiel.

    So das wars erst auf die schnell. Wenn mir noch was einfällt update ich die Liste.

    Also da steckt schon eine Menge Arbeit drin. Daher war ich der Meinung das es relativ gut ankommt :D und ich den einen oder anderen für eine Unterstützung begeistern kann.
    Entweder ich habe es falsch presentiert, es liegt an der fehlenden doku oder das ganze ist Misst ;( . Egal ich werde weiter machen :rock:

  • Vermutlich liegt das an der fehlenden Dokumentation.
    Ich werde hier die Dokumentation in laufe der Zeit vervollständigen.

    Kann ich nicht beurteilen (sprich noch nicht angetestet) aber es scheint: die wichtigste Arbeit muß noch erledigt werden.

  • Hallo zusammen,

    ich hofe es ist nicht schlimm das ich dieses alte Thema ausgrabe.

    Ich wollte mein Interesse bekunden und fragen wie es denn um Roma() steht.

    Auf github ist leider seit letztem Jahr nicht viel passiert, aber ich hoffe das es doch noch weiter geht.

    Denn ich würde dieses Framework gern für ein Projekt nutzen.

    Ich natürlich auch gern bereit mich zu beteiligen ;)

    Gruß

    Einmal editiert, zuletzt von Grimli (27. November 2017 um 21:23)

  • @Churanos

    schön das sich nach langer Zeit dennoch jemand für das Framework interessiert. Ich musste leider dieses Vorhaben auf eine unbestimmte Zeit auf Eis legen, da ich beruflich andere Sprachen erlernen musste und zeitlich nicht mehr dazu kamm es weiterzuentwickeln. Da ich nun wieder ein wenig Zeit habe können wir zusammen dieses Framework gerne finalisieren.

  • Ich hätte dazu einen "etwas anderen" Vorschlag:

    Was würdest Du davon halten, wenn das ganze ähnlich wie in Pascal "objektorientiert" gemacht wird?

    Folgendermaßen: In einem INI File steht z.B. folgender Text für alle Controls durchlaufend:

    und das für alle Controls fortlaufend. (Variablenzuweisung würde dann bspw. über Assign() funktionieren oder wie das heißt, bin mir grad nicht sicher)

    Das AutoIt-Skript rendert das Ganze, nämlich zuerst mit einer anderen INI-Datei, in der mit ähnlichem Aufbau die Infos zur Form stehen etc.

    Wie man ja sieht in der letzten Zeile, wird ActionXXX ein Funktionsname zugewiesen. Diese Actions könnten über separate Dateien im AutoIt-Skript-Format oder direkt über das Skript laufen, je nach dem, wie es dir passen würde.

    Ich weiß, dass das nicht ganz in Einklang mit dem was du wolltest, steht, aber das wäre auch eine Möglichkeit, wie man das ganze über eine eigene IDE gesteuert sehr gut hinbekommen könnte. So etwas wie das mit HTML könnte man über ein solches Skript auch hinbekommen, z.B. über ein Attribut wie tag=h1 und man setzt dann auf die Systemfonts, wie es sonst in HTML "üblich" wäre (z.B. Times New Roman, 16pt, bold).

    Würde mich auch gerne bereit erklären, mit dieser "neuen" Idee an dem Framework mitzuwirken. :)

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Hallo olfibits,

    ich verstehe zwar im ganzen was du vorhast, jedoch hat es keinerlei berührungspunkte mit meinem Framework, denn ich möchte komplett von der AutoIt/Windows GUI weg.

    Zudem ist das auch plain in AutoIt mit (onEvent Mode) umsetzbar, so eine kleine UDF ist relativ fix umgesetzt, was die INI ausließt und mit den Werten eine GUI erstellt. Hierfür ist nichteinmal ein extra Scrpit notwendig.

    Mein Ziel mit meinem Framework ist es:

    • Frontend und Backend strikt zu trennen
    • HTML, CSS & Javascript als Frontend
    • AutoIt als Backend
    • einheitliches Applikation Muster (MVC)
    • UDFs als Packages (z.B wie npm, composer, yarn usw.)
    • eine Framework cli
    • usw.

    Hierfür habe ich noch etliche Herausforderungen. Für die ich durchaus Hilfe benötige.

    Werde demnächst mit dem Projekt weitermachen. Würde mich über Hilfe freuen.

  • Ach so ok, dann habe ich das falsch verstanden. Dachte es sollte ein HTML-programmierbares Win32 GUI werden.

    Dann bin ich out :)

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Die strikte Trennung sagt mir persönlich zu und ist für mein Vorhaben auch genau das richtige. Leider habe ich die Oberfläche mit dem IE nicht zum laufen bekommen. Es tauchen keine Fehlermeldungen auf und das Window wird auch angezeigt, die IE-Instanz scheint aber das HTML nicht zu laden. Ich hatte bisher noch nicht die Gelegenheit etwas genauer rein zu schauen, das werde ich aber in den nächsten Tagen nachholen.

    Wenn als Ausgabe der Browser gewählt wird, klappt alles ohne Probleme, das mag evtl. an Win10 liegen.

    Eine anderer Punkt, den ich ansprechen wollte, ist die generelle Struktur. Ich persönlich bin kein Fan von langen Funktionsnamen, was bei AutoIt ja durchaus vorkommen kann. Wäre denn eine Umsetzung mit AutoItObject eine Option?

    Ich versuche mich noch langsam an das Framework ran zu tasten, daher halte ich mich noch zurück ;)

    olfibits Deine Idee mit dem generieren von win32 GUI Elementen ist gut und kam mir auch schon des öfteren, da das im AutoIt Code ihmo unübersichtlich werden kann. Ich würde da aber auf ein Format zurück greifen das bereits verwendet wird und eine UDF zur Anbindung bauen. Das wäre doch bestimmt eine Aufgabe für dich.

    4ern Wenn die Entwicklung weiter geht (auf Github?) würde ich da gern mit einspringen. Ich behalte schon mal im Auge :)

    Gruß

  • Leider habe ich die Oberfläche mit dem IE nicht zum laufen bekommen. Es tauchen keine Fehlermeldungen auf und das Window wird auch angezeigt, die IE-Instanz scheint aber das HTML nicht zu laden.

    Ja das stimmt. Weshalb auch immer funktioniert die ie navigation nicht, sodass ie nicht zur gewünschten url navigiert, daher auch die leere Seite.

    Ich habe mir auch überlegt ie komplett zu streichen und chrome als app mode zu verweden, denke das wird damit viel besser laufen. Problem dabei ist, dass beim Endnutzer auch Chrome installiert sein muss... evtl. kann man ja Chromium integrieren, jedoch kenn ich mich da überhaupt nicht aus.

    Ich persönlich bin kein Fan von langen Funktionsnamen, was bei AutoIt ja durchaus vorkommen kann

    Das ist natürlich persönliches empfinden und jeder tickt da unterschiedlich. Der Grund für die langen Funktionsnamen ist, dass AutoIt kein Namespace unterstützt und somit jeder Funktion einmalig sein muss. Somit musste ich mir was überlegen damit sich die Framework Funktionen sich nicht mit der späteren Anwendung und Packages im Weg stehen. Daher habe ich mich entschieden den Namespace einfach an den Funktion voranzustellen.

    Hat auch den Vorteil, dass man an Namen sofort erkennt, wo sich die Funktions Dekleration befindet.

    Bsp:

    app_au3_—_roma.png

    Eine anderer Punkt, den ich ansprechen wollte, ist die generelle Struktur. Ich persönlich bin kein Fan von langen Funktionsnamen, was bei AutoIt ja durchaus vorkommen kann. Wäre denn eine Umsetzung mit AutoItObject eine Option?

    Ursprünglich wollte ich das auch Objekt orientiert aufbauen. Jedoch ergeben sich dabei einige Problem:

    • Die Udf wurde von ProgAndy gebaut und von ihm hört man seit einigen Jahren nichts mehr. Daher gibts es kaum support sollte mal etwas nicht laufen.
    • Mein Ziel ist es das Framework mit so wenig udfs wie möglich zu bauen. Weitere sollen dan durch den Entwickler als Packages geladen werden.
    • Nicht jeder in der AutoIt Szene mag Objekt orientiert.
    • Nur wenige kennen sich mit der AutoItObject aus, sodass spätere Fragen in Foren nur von sehr wenigen beantwortet werden können
    • ich bin mir nicht ganz sicher ob bereits vorhanden user udf damit kompatibel sind.

    Wenn die Entwicklung weiter geht (auf Github?) würde ich da gern mit einspringen. Ich behalte schon mal im Auge

    Ich habe gesten schon gestartet ie rauszuschmeisen und chrome zu integrieren.

    Wenn du magst könnten wir mal ein Schlachtplan erstellen was und wir das ganze angehen?

    EDIT:

    Wer gerne mithelfen oder ideen und anregung teilen möchte, kann gerne in die Slack Gruppe beitreten.

    SLACK-CHANNEL

  • Was du benötigst ist nicht Chrome selber, sondern deren Web Engine. Sie verwenden die Blink Engine welche du problemlos in dein Projekt intigrieren kannst. Den Git dazu findest du hier: https://chromium.googlesource.com/chromium/blink

    Blink selber steht unter folgenden Lizenzen:

    Three-clausel BSD

    GNU LGPL v2.1

    Bedeutet aber auch, dass dann entsprechend Projekte die mithilfe deiner UDF erstellt werden nicht einfach kommerziell genutzt werden können. Das sind dann so Rahmenbedingungen im Urheberrechts Dschungel. Nun ja, wie dem auch sei. Ich würde dir raten eine Web Engine zu nutzen da du dann von den entsprechenden Browser (und ob die Nutzer diesen installiert haben) unabhängig bist.

    €dit: Sag mal, welchen Editor nutzt du für AutoIt? Der schaut ja fancy aus :D

    €dit Nr.2:

    Zitat
    • Die Udf wurde von ProgAndy gebaut und von ihm hört man seit einigen Jahren nichts mehr. Daher gibts es kaum support sollte mal etwas nicht laufen.
    • Mein Ziel ist es das Framework mit so wenig udfs wie möglich zu bauen. Weitere sollen dan durch den Entwickler als Packages geladen werden.
    • Nicht jeder in der AutoIt Szene mag Objekt orientiert.
    • Nur wenige kennen sich mit der AutoItObject aus, sodass spätere Fragen in Foren nur von sehr wenigen beantwortet werden können
    • ich bin mir nicht ganz sicher ob bereits vorhanden user udf damit kompatibel sind.

    Ich bin wahrscheinlich einer der wenigen Nutzer die sich mit der UDF komplett auseinander gesetzt haben. Die UDF selber ist fertig gestellt und mir sind keine Bugs aufgefallen, weshalb weiterer Support für diese UDF schlichtweg nicht nötig ist. Sie läuft einwandfrei mit der derzeitigen AutoIt Version und wird es vermutlich noch die nächsten Versionen auch noch tun, vorrausgesetzt an AutoIt wird grundlegend nichts verändert. Zudem braucht ja lediglich nur der Entwickler der UDF, also du, die nötigen Kenntnisse der AutoItObject UDF. Die Objekte die du dann zur Verfügung stellst und dessen Funktionsweise wirst ja dann wohl du dokumentieren und dafür im Forum Support bieten. Wird ja schließlich auch deine UDF. Falls du dich für die AutoItObject UDF entscheiden solltest und auf Probleme stößt, kannst du dich bei mir per PM melden.

    Einmal editiert, zuletzt von Yjuq (1. Dezember 2017 um 11:30)