Liebe Community.

Ich habe im vergangenen dreiviertel Jahr an einem Projekt gearbeitet, aus dem langsam aber sicher sich ein Framework gebildet hat. Mittlerweile programmiert seit 2 Monaten ein Kumpel von mir, der mit mir zusammen wohnt und Informatik an der Goethe Uni studiert, ebenfalls am Projekt mit.
Da das Framework nun immer mehr Form annimmt und ich es demnächst über die Crowd-Funding-Plattform startnext.de einstellen möchte, wollte ich es hier vorstellen um ein wenig Kritik einzuholen :).

(Sollte dies nicht der richtige Ort für eine Projektvorstellung sein - sorry, konnte nichts besseres finden :>)

Hauptziel des Frameworks ist, dem Entwickler Zeit zu sparen (daher auch der Name "Riesenfaultier"). Es soll komplexe Vorgänge des alltäglichen Programmierens mit einfachen Schnittstellen zur Verfügung stellen.

Komponenten

• Paketsystem - das Framework ist komplett modularisiert und bietet als Schnittstelle für Erweiterungen eine umfangreiche Paketverwaltung an. Ein einfaches Paket besteht aus einer kurzen XML-Konfigurationsdatei sowie einer jar-Datei. Fehlende Pakete können über ein zentrales Repository nachgeladen werden oder bei der Entwicklung eines eigenen Paketes beigelegt werden.
• Speicherverwaltung - ob Daten nun im lokalen Dateispeicher, in einer Datenbank oder auf einem weit entfernten Server gespeichert werden sollen - die zentrale Speicherverwaltung übernimmt dies und bietet dem Entwickler einfache Methoden an, um Daten zwischen lokalem Speicher und entfernten Server zu synchronisieren.
• Events - das Auslösen und Abfangen von Ereignissen stellt den grundlegenden Aufgabenbereich eines Frameworks dar. Dabei darf es hier natürlich auch nicht fehlen - dank der Java-Reflect-API auch mit dynamischen Inhalten statt nur mit umständlichen Interfaces.
• Mehrsprachigkeit - übersetzt man seine Anwendung von Deutsch auf Englisch, so erreicht man mit wenig Aufwand viele neue potentielle Kunden. Doch die meisten Programme werden am Anfang nicht auf Mehrsprachigkeit ausgelegt oder die Einarbeitung mehrsprachiger Inhalte ist umständlich - hier wurde Mehrsprachigkeit als ein zentrales Konzept implementiert und steht euch von Anfang an zur Verfügung.
• Plattformunabhängigkeit - Windows, Linux oder Mac? Server, Desktop-PC oder Handy? Das Framework kann auf sämtlichen Plattformen (getestet bei Servern mittels Tomcat) ausgeliefert werden und bietet so eine unglaublich hohe Flexibilität.
• Templatesystem - Wir bauen das Templatesystem "StringTemplate" mit ein. Dadurch wird es möglich, in Sprachvariablen z.B. dynamische Inhalte einzubauen, um Grammatik (wie Ein- und Mehrzahl) anzuwenden.
• Flexibilität - Nicht nur, dass das Framework sowohl auf Servern als auch PCs läuft: Sämtliche Bibliotheken (wie z.B. StringTemplate) sind über eigene Interfaces verfügbar, sodass man später aus div. Gründen eine Bibliothek einfach austauschen kann - man muss nur die Interfaces überschreiben.
• Konfiguration - Konfigurationsdateien können einfach erstellt und verwaltet werden.
• Debugging - Ein Tool ist in Planung (Open Source), dass hilft, Fehlermeldungen mittels unterschiedlicher Level anzuzeigen bzw. auszublenden.

Probleme
Wir haben ein großes Problem: Wir möchten auch eine standardisierte grafische Oberfläche benutzen. Diese muss dynamisch genug sein, damit Templates kleine Änderungen einführen können.
Unsere einzige Idee wäre derzeit HTML, da die Swing-UI nicht dynamisch genug ist. Oder irre ich mich? :>

Repository-Server
Über Repository-Server können Listen von Paketen abgerufen werden. Dabei wollen wir eine grundlegende Repository-Software ebenfalls Open Source zur Verfügung stellen. Bei der kostenpflichtigen Version ist es möglich, Pakete nicht nur anzubieten, sondern auch zu verkaufen - wobei auf eine Förderung von Open Source Projekten auf zwei Wegen geachtet wird:

1. Förderung von Open Source Projekten
Folgendes Szenario: Entwickler A entwickelt das Paket A1 und stellt dies Open Source zur Verfügung. Entwickler B entwickelt das Paket B1, welches auf A1 basiert, und möchte dieses verkaufen. Nun hat Entwickler B die natürlich Möglichkeit, Entwickler A Geld als Dank für die abgenommene Arbeit zu spenden - er kann aber seinen eigenen Gewinn auch direkt an die Abgaben an Entwickler A binden, sodass Entwickler A einen Prozentsatz des Gewinns von Entwickler B erhält.
Im Gegenzug gehen vom Gewinn von Entwickler B ein geringerer Anteil an den Betreiber des Servers ab.

2. Förderung von Sozialen Projekten
Um soziale Projekte und Ideen zu Unterstützen, können Entwickler, die ein Paket verkaufen wollen, einen zweiten Preis nennen od. das Paket für soziale Projekte kostenfrei zur Verfügung stellen. Diesen Preis müssen Leute zahlen, die die Software für soziale Projekte nutzen möchten. Dies geht nur unter Angabe einer ausgearbeiteten Projektidee (die nicht veröffentlicht wird), um sicher zu stellen, dass es sich tatsächlich um ein soziales/gesellschaftliches Projekt handelt.



Geplante Software
Wir haben aktuell folgende Software für das Projekt fest eingeplant, die auch veröffentlicht und anderen Entwicklern/Projektleitern zur Verfügung gestellt werden soll:

• Repository-Server Frei - soll Open Source für die Betreibung eines eigenen Repository-Servers für kostenlose Pakete zur Verfügung gestellt werden
• Repository-Server kommerziell - basiert auf dem freien Repository-Server und bietet (siehe oben) diverse Funktionen für die kommerzielle Verwendung von Paketen; wird verkauft werden
• Cloud Storage Communicators - bietet eine einheitliche Schnittstelle für unterschiedliche Cloud-Storage-Anbieter (Dropbox, Google Drive, Mega) an; mögliche Verwendung: Backup von privaten Daten über die Cloud, Cloud Storage Client
• Debugging Tool - Ein OpenSource Tool, dass hilft, Fehlermeldungen anhand unterschiedlicher Fehlerlevel (schwere der Fehler) auszuwerten.
• Server Installation Tool - Ein OpenSource Tool, dass hilft, Pakete bei Server-Applikationen zu installieren und diese zu aktualisieren/installieren.

Und damit verabschiede ich mich auch schon. Was sagt ihr zu der Idee? Die Framework-Komponenten sind bereits umgesetzt, sie müssen lediglich noch ausgearbeitet und anschließend von mehreren Entwicklern getestet werden. Habt ihr noch Ideen, wie man das ganze verbessern könnte?

Wenn ihr nähere Infos haben wollt, dann sagt Bescheid - eine umfangreiche Dokumentation ist auch bereits in Arbeit :).

Liebe Grüße,
SargTeX


Codebeispiele
Damit ihr euch auch etwas darunter vorstellen könnt - hier einige Codebeispiele!

1. Ein Objekt erstellen
Wir wollen ein Objekt in der Datenbank hinterlegen. Oder im Dateispeicher. Dies ist einfach:


2. Ein Objekt bearbeiten (ID = 42)



3. Ein Objekt bearbeiten (Key = "meinname")



4. Ein Paket installieren

Zum Thema Ausprägungen:

Es gibt dabei unterschiedliche Editoren, die letztendlich die Objekte bearbeiten/auslesen/löschen usw. Aktuell gibt es die folgenden:

• JsonEditor: Speichert die Daten im Json-Format im Dateispeicher ab
• MySQLEditor: Speichert die Daten in einer MySQL-Datenbank ab
• MegatheriumServerEditor: Übermittelt die Daten an den Megatherium Server (beispielsweise Account-Daten oder ähnliches)
• MultipleEditor: Verknüpft mehrere Editoren miteinander

Wird ein Objekt mittels des MultipleEditors erstellt, so wird es beispielsweise bei meinem Programm an den JsonEditor und an den MegatheriumServerEditor versendet. Dies verfolgt den Zweck der Datensynchronisierung und des offline Caches: Auf der einen Seite soll der Datensatz auf meinem Server angelegt werden, auf der anderen Seite soll er aber lokal zwischengespeichert werden. Aktuell habe ich aber noch keine Regulierung zum automatischen abrufen der Daten eingebaut, d.h. verändert man die Daten beispielsweise von einem zweiten PC aus, hat man lokal (noch) veraltete Daten.


Die Konfiguration hiervon erfolgt folgendermaßen:


Konfigurationen (von der beliebig viele angelegt werden können) werden atm im Json Format im Dateispeicher hinterlegt. Hier werden beispielsweise Konfigurationen für die Editoren hinterlegt: Der "localEditor" wird bei Datenmodellen verwendet, die ausschließlich im lokalen Dateispeicher abgelegt werden sollen (beispielsweise das "Module"-Modell: Es macht keinen Sinn, nach der Installation eines Moduls dieses auf einen Server zu schicken). Die "editors" werden vom MultipleEditor der Reihe nach aufgerufen, wobei ich hier allerdings noch keine Lösung für das Lesen von Listen gefunden bzw. implementiert habe.

Die Konfiguration kann dabei einerseits über die Dateien, aber andererseits auch zur Runtime geschehen, hier ein Code-Beispiel:


Die Konfigurationen werden automatisch gespeichert, wenn das Programm beendet wird. Ebenso wie Fehlermeldungen, die automatisch in eine error.log Datei bei Programmende geschrieben werden.
(Zugegeben, im Beispiel sind die Namensgebungen noch nicht sonderlich ausgeklügelt - habe die Configs früh am Anfang geschrieben. Werde das natürlich überarbeiten)




@JavaFX:
Danke. Habe ich gestern zufällig auch gelesen, werde ich mir mal anschauen Ist das denn dynamisch genug?
Die Oberfläche muss es ermöglichen, dass ein Plugin zu einer bestehenden Oberfläche bspw. eine Checkbox hinzufügt. Bei HTML würde ich dies mittels Templatevariablen/Templateevents ermöglichen.

Updates
Wir ändern nun die Log-Speicherung. Fehler werden üblicherweise bei Programmende in einer .log-Datei aufgelistet und gespeichert. Dies bringt aber nichts bei Servern, da das Programm meist durchgehend und wochenlang läuft, und man erst durch Beenden des Programmes den Fehlerlog erhalten würde. Daher bauen wir ein, dass man in die Konfiguration schreiben kann, dass der Errorlog alle X Sekunden/Minuten/Stunden automatisch gespeichert werden soll. Das gleiche System könnte man auch bei Datenbanken im Dateispeicher (siehe JsonEditor) einbringen, um Datenverlust zu verhindern, gleichzeitig aber hohe Schreibraten zu meiden. Alternative wäre eine flush() Methode, die bei Editoren aber eigentlich nicht vorgesehen ist. (?)

Neue Tools
Darüber hinaus haben wir eben beschlossen, 2 Tools mitzuentwickeln: Das eine ist ein Console-Tool, dass man zum Debugging einsetzen kann, und das einen u.a. die Fehlermeldungen in unterschiedlichen Leveln anzeigen kann. Das andere Tool ist ein Update/Install-Tool für die Server: Bei .war Applikationen würde ein Update-Mechanismus wie bei den Clients sehr schwer werden. Stattdessen packt das Tool die gewünschten Pakete zusammen in ein Programm, installiert diese und fügt die Datei in eine .war Applikation ein. Anschließend kann das Tool die Applikation automatisch installieren (Daten in die Datenbank usw), oder der Anwender installiert sie selbst über einen Servlet-Aufruf.


Flo
Übrigens habe ich auch noch vergessen zu erwähnen, dass ein Kumpel von mir, der mit mir zusammen Informatik an der Goethe-Uni studiert, seit 2 Monaten mich bei der Arbeit unterstützt :).

Es kann sowohl auf Application Servern als Server dienen als auch bei Desktop-Umgebungen implementiert werden. Das Server-Modul/Paket wurde auf Servlets ausgelegt und mittels Tomcat getestet, dürfte alternativ aber auch auf Glassfish usw. laufen.


Haben wir nicht vor, aber erst muss noch ein wenig dran gearbeitet werden :D. Wenn dich bestimmte Stellen interessieren, poste ich aber gern Beispielcode. In ein paar Tagen/wenigen Wochen sollte das Grundpaket auch so weit sein, dass ich es auf Github veröffentliche.


Kannst du mal ein Beispiel posten? Die Eventverwaltung ist aktuell noch der Teil, an dem ich am meisten überarbeiten muss. Sie funktioniert mittels der Reflect API (Beispiele siehe unten) UND Interfaces, hat aktuell aber noch gewisse Schwierigkeiten bzgl. der Stabilität. Beispielsweise gibt es oft Probleme mit den Parametern: Werden Primitives verwendet oder Abgeleitete Klassen (also statt "String" "Object" oder ähnliches), kommt es zu Problemen, dass die gesuchte Methode nicht gefunden werden kann.


Das ist richtig. Das Problem bei den meisten Entwicklern ist jedoch (zumindest war dies auch bei mir so), dass das Einpflegen von Mehrsprachigkeit zunächst viel Arbeit ist: Man muss sich darum kümmern, dass die Sprachvariablen abgespeichert werden, ggf. aktualisiert werden können, verwaltet werden usw., darüber hinaus sind auch einige Schritte nötig, um diese Sprachvariablen dynamisch zu gestalten.
Zwingen wollen wir die Entwickler allgemein zu nichts. Wir wollen ihnen aber die Möglichkeit bieten, Mehrsprachigkeit einzubinden, ohne, dass sie sich um all diese organisatorischen Dinge kümmern müssen - es ihnen also möglichst stark vereinfachen.


Bei der Apache Commons Configuration hat mich der Zugriff auf die Variablen gestört. Angenommen, du möchtest auf den UserAgent zugreifen:




Wir haben hier bewusst mit Klassen und Methoden gearbeitet. Unser erster Ansatz sah zunächst ähnlich wie bei Apache aus, jedoch finde ich es wesentlich angenehmer, wenn ich weiß, dass der Konfigurationseintrag auch existiert (siehe Methoden, auf die bei der Entwicklung mit einer Dokumentation zugegriffen werden kann). Außerdem hat man hier vorgefertigte Datentypen - UserAgent ist immer ein String und kann nicht fälschlicherweise als Integer abgerufen werden. Außerdem kann man ganze Objekte somit abspeichern, und muss sich anschließend nicht darum kümmern, diese komisch zu casten, parsen o.ä.
Insgesamt haben wir aber einige andere Apache-Pakete eingebaut, darunter Commons IO, Commons Compress und HttpClient. Bis zum Release soll es aber so weit sein, dass man in der Regel nicht die Apache-Klassen verwendet, sondern auf unsere Klassen zugreift - die im Umkehrschluss dann die Apache-Klassen aufrufen und verwenden. Dies hat zwar den Nachteil für Leute, die sich mit den Bibliotheken bereits auskennen, dass sie sich in unsere Dokumentation einlesen müssen, aber umgekehrt den großen Vorteil, dass Entwickler auf Wunsch hier die bisherigen Bibliotheken durch neue ersetzen können, die bspw. performanter sind.
Wie das Ein-/Aussetzen von Bibliotheken in der Praxis aussehen könnte, weiß ich noch nicht - aktuell könnte man den Quellcode einfach bearbeiten, um Framework-weit eine bessere/schnellere/... Bibliothek einzubinden. Cool wäre es natürlich, wenn dies mittels einem Modul/Paket funktioniert :).

In ein/zwei Tagen veröffentliche ich eine kleine Website dazu. Dort sind nochmal ein paar Tutorials/Codebeispiele zu finden sowie ggf. eine halbfertige Dokumentation, durch die man auch erste Eindrücke sammeln kann.

Datanucleus kannte ich davor btw noch gar nicht, sieht aber echt interessant aus :). Maven ist meines Wissens nicht für den Anwender gedacht, unser Ziel war eher ein Paketsystem ähnlich dem des PHP-Frameworks "WoltLab Community Framework". Durch Installation sind auch nur minimale Änderungen möglich - wie beispielsweise das Hinzufügen eines neuen BBCodes oder dem Hinzufügen einer einzelnen Checkbox. Eine ähnliche Flexibilität wollen wir auch im Java-Framework implementieren.



Beispiel Event-Manager

Events auslösen



Folgendermaßen können Events abgefangen werden: