Nach vielen vielen Monden habe ich es am Ende doch mal fertig gebracht mein altes Zeiterfassung-Projekt bei Github hoch zu laden. Wobei das komplizierteste noch war das Framework "hübsch" zu machen. Das Modul ist jetzt auch mehrsprachig.
Frameworks gelten ganz ganz oft als etwas sehr kompliziertes und mächtiges Werkzeug, das nur von wenigen auserwählten entwickelt und designed wird. Wenn ein Framework etwas nicht kann wird es meistens so hingenommen und darauf gehofft, dass es vielleicht doch noch irgendwann mal eingebaut wird. Meistens würde man sich nie trauen, sich dabei einzubringen oder einzumischen.
Man selbst ist ja einfacher "Anwender" und wie die eigenen Anwender, die das eigene Programm nutzen, das wieder das Framework nutzt, sollte man sich nicht die Dinge einmischen, von denen man keine Ahnung hat.
Ich habe über die Jahre doch ein paar Frameworks gebaut. Gute, schlechte, noch schlechtere und auch welche, die durch die allgemeine Frameworks ersetzt wurden. Auch mal ein Bugfix für ein vorhandenes Framework war dabei.
Wichtig ist dabei, dass man sich klar wird, dass Frameworks im Kern meistens alles andere als hoch komplex sind. Das würde schon dem
Zweck des Frameworks widersprechen, das ja für möglichst viele Anwendungszwecke funktionieren soll. Der Core ist meistens sehr einfach und klar strukturiert. Komplexität kommt meistens über Zusatzfunkionen rein, die wieder rum nur die Kernfunktionen bedienen. Wenn diese Kernfunktionen gemischt werden und kann es am Anfang sehr unübersichtlich erscheinen, weil teilweise nicht ganz klar ist, was wofür da ist.
Bei React mit Hooks kann selbst das Mischen von useState und useEffect teilweise kompliziert sein, weil aus der Sicht des Entwicklers vielleicht, von diesen Funktionen was anderes Erwartet wird, als im Framework-Kern damit wirklich erreicht wird.
Frameworks machen keine Zauberrei aber dafür sehr viel Referenz-Verwaltung. Meiner Erfahrung nach beschäftigt man sich im Framework-Kern zu 75% allein damit Instanzen und Referenzen zu erzeugen und zu verwalten.
Um das ganze etwas zu verdeutlichen habe ich mich einmal hingesetzt und in unter einer Stunde (hatte ich mir auch so vorgegeben) ein kleines Framework gebaut, das useState und useEffect reimplementiert und zeigt, wie man das Verhalten dieser Funktionen nutzt, aber auch, welche Funktion für das Framework wirklich dahinter steckt. Weil am Ende kommt man zu meist immer zu selben Strukturen, die bei allen Frameworks immer nur etwas anders benannt und implementiert sind.
Ich habe ein älteres (letztes Jahr September) angefangenes aber nie fertig gewordenes Shopware Plugin nun bei GitHub hochgeladen, in der Hoffnung, dass noch jemand was damit anfangen kann. Es fügt z.B. ein zusätzliches Feld zum Product-Slider Emotion-Element hinzu und ändert das Template für bestimmte Artikel im Slider.
Ich habe etwas mit State-Management in Java herum experimentiert und mir etwas geschrieben, um den State von Web-Apps (Vue.js, React, AngularJS,..) auf einen Server auszulagern. So dass sich die States und Actions der verschiedenen Clients gegenseitig beeinflussen können (Datenaustausch), aber private Daten wie Tokens trotzdem für die einzelnen Clients isoliert bleiben. Neben den Reducern gibt es noch Facets für die Anpassung der Ausgabe (so etwas wie Getter in Vuex).
Ich wollte dann einmal das Grundsystem (State-Manager, Interfaces, Server + Controller) in einem Mave-Repository ablegen und die konkrete Implementierung der Reducer, Facets und Filter dann sauber getrennt in einem eigenen Projekt haben.
Das Repository sollte einfach bei Github liegen und nicht in eines der öffentlichen und großen mit rein genommen werden, da es ja erstmal ein Proof-Of-Concept für meine Idee zu verteilten Daten ist. Ich habe mich dabei an diesem DZone-Artikel orientiert.
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.4</version>
<scope>provided</scope>
</dependency>
<!-- .... und noch mehr ..... -->
</dependencies>
</project>
Den Inhalt aus target/mvn-repo/hp-globalstate/hp-globalstate-core/ habe ich dann in ein Github-Projekt gepackt und hochgeladen. Das 2. Projekt kommt dann dieses dann hinzu:
public class Server {
public static void main(String[] args){
GlobalStateServer server = new GlobalStateServer();
List<Reducer> reducers = new ArrayList<>();
reducers.add(new de.hannespries.test.Reducer());
List<FacetFilter> facets = new ArrayList<>();
facets.add(new DefaultFacetFilterByToken(true));
Irgendwann fängt man an aus seinem großen Framework einzelne kleine Module heraus lösen zu wollen. Die will man dann als Composer-Requirements wieder einbinden. Zum Glück geht das sehr einfach, indem man einfach ein Repository zu seiner composer.json hinzufügt: