Repositories - oder wie machen wir das mit BC2?

Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

Bekanntermaßen nutzt BC2 vielerorts die "Arbeit anderer", beispielsweise beim Datenbank-Zugriff (Doctrine), bei der Behandlung von ZIP-Dateien (PCLZip), beim Versenden von Mails (Swift oder PHPMailer), in Sachen WYSIWYG (CKEditor), usw. Früher haben wir diese ganzen Voraussetzungen per eigener/einzelner Module zur Verfügung gestellt, das ist aber unnötige Arbeit, insbesondere bei Bibliotheken, die eigentlich keinen anderen Zweck haben, als "da zu sein". (Wie eben Doctrine.)

Da nicht nur wir solche "Probleme" haben, existiert ein Werkzeug namens Composer, welches wir jetzt auch nutzen. Hier definiert man einfach, was man neben seinem eigenen Code sonst noch so braucht, und Composer sorgt dafür, dass das alles vorhanden ist. Praktischerweise löst es dabei auch Abhängigkeiten auf, die vorausgesetzte Komponenten haben. Das heißt, wenn wir z.B. sagen, wir brauchen XYZ, und XYZ braucht wiederum A, dann kommt A automatisch auch mit. Und wenn A seinerseits B braucht... Und so weiter.

Alles, was man auf diese Weise an Voraussetzungen runterlädt, landet in einem Ordner "vendor", welcher in unserem derzeitigen Repository leer ist. Das soll auch so sein, wenn wir wollen ja nicht den Quellcode anderer duplizieren und dann bei uns aktuell halten. Das bedeutet allerdings auch, dass man sich nicht unser BC2 Repository von GitHub runterladen und das dann installieren kann, weil die ganzen Voraussetzungen fehlen. Für Entwickler sollte das normalerweise keine Hürde darstellen, da sie mit einem einfachen Aufruf von Composer alles runterladen können, was fehlt. "Normale Anwender" können alles Notwendige von unserer Homepage runterladen, denn natürlich werden wir nach wie vor fertige Bundles zur Verfügung stellen.

Nun haben wir aber noch Abhängigkeiten anderer Art: Die Engine läuft prinzipiell auch ohne Module, aber nicht umgekehrt. Andererseits können Module Änderungen erfahren, ohne dass es eine neue Version der Engine (des Core) gibt. Daher macht es Sinn, die Module außerhalb des Engine-Repositories in jeweils eigenen Repositories abzulegen. Letztlich könnte man die Engine ganz ohne Module installieren und alles, was man haben will, über denn Addons Katalog nachladen. Da das Anfänger überfordern kann - wer kann schon auf Anhieb beurteilen, ob er das Modul XY wirklich braucht -, könnte man in den Installer einbauen, dass er einen Basis-Satz an Modulen im Anschluß an die Engine-Installation herunterlädt und installiert.

Worauf ich hinaus will:

Repository "BC2_Engine"

https://github.com/BlackCatDevelopment/BC2_Engine

Dieses Repository würde nur die Engine, also die Verzeichnisse CAT und languages (und eventuell ein leeres temp) beinhalten. Das Unterverzeichnis CAT/vendor muss durch Aufruf von Composer gefüllt werden.

2018-10-30 17_26_57-P__BlackCat2_cat_engine.png
2018-10-30 17_26_57-P__BlackCat2_cat_engine.png (3.79 KiB) 4589 mal betrachtet

Module

Jedes (!) Modul hat ein eigenes Repository, wie es ja z.B. bei catGallery oder blackNews der Fall ist. Analog zu BC1 gibt es ein Katalog-Repository mit Informationen zu allen verfügbaren Modulen, welches die Basis für den Addons Katalog ist. Das gilt natürlich auch für Themes und Templates, sofern sie über den Addons Katalog installierbar sein sollen.


Installation

Der Installer verfügt bereits über zwei Varianten, nämlich "Einfach" und "Erweitert". Im einfachen Modus könnte der Installer hingehen und die sinnvollsten Module sowie ein Standard-Template und ein Backend-Theme aus den jeweiligen Repositories holen. Die dafür notwendigen Methoden sind in der Engine vorhanden. Einzige Voraussetzung ist, dass ein Zugriff auf GitHub existiert. Im erweiterten Modus könnte man dem Benutzer den Addons Katalog mit einer Vorauswahl anzeigen, so dass er auf Wunsch weitere oder alternative Module auswählen kann, die dann ebenfalls automatisch installiert werden.
Die Engine samt fertig gefülltem vendor-Ordner liegt dem Installer dann übrigens als ZIP bei, das heißt, kein "normaler Anwender" muss sich mit Composer rumschlagen.


Vorteile

Durch die saubere Trennung von "reinem Core" und "Zusatzkomponenten" ist es viel einfacher, Module, die wir normalerweise mitliefern (müssen), außerhalb des normalen Releasezyklus zu aktualisieren. Bisher müssen wir diese nämlich zweimal vorhalten, einmal innerhalb des Core-Repositories und einmal als getrenntes Modul.

Anwender, die sich mit Composer auskennen, können die vorausgesetzten Komponenten jederzeit auf eigene Faust aktualisieren. Das wird man in der Regel nicht auf Produktivsystemen tun, sondern nur in Entwicklungsumgebungen.

Zudem wird es auf diese Weise möglich, die Engine selbst über den gleichen Mechanismus zu aktualisieren.


Nachteile

Für nicht so Geübte wird der Wildwuchs an Repositories vielleicht etwas verwirrend sein. Allerdings ist GitHub ohnehin nicht die geeignete Quelle für "normale Anwender". ;)


Liste der Repositories (fortlaufend)
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
Morpheus
Beiträge: 1050
Registriert: Do 8. Aug 2013, 10:49
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von Morpheus »

Ufff, also für mich klingt das:
Im einfachen Modus könnte der Installer hingehen und die sinnvollsten Module sowie ein Standard-Template und ein Backend-Theme aus den jeweiligen Repositories holen
ganz super und wer mehr will nimmt das:
Im erweiterten Modus könnte man dem Benutzer den Addons Katalog mit einer Vorauswahl anzeigen, so dass er auf Wunsch weitere oder alternative Module auswählen kann, die dann ebenfalls automatisch installiert werden.
Und genau so stell ich mir ein einfaches CMS vor, was schon bei der Installation ohne großes Abfragen abläuft.

Den Anwender der das ausprobieren möchte nutzt erst mal den einfachen Modus und installiert sich den Rest über den Katalog. Er wird sicherlich Github nicht nutzen wollen. Der experimentier freudige Anwender wird den erweiterten Modus nutzen wollen.
Ein Entwickler nutzt auch erst mal den einfachen Modus und guckt dann auf Github nach.
Meine Meinung ;)
Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen!
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
creativecat
Beiträge: 1430
Registriert: Mi 6. Feb 2013, 12:41
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von creativecat »

Habs schon gesehen, dass du aktiv warst :daumen:
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

Bootstrap wandert in den vendor-Ordner. Unser Asset Helper kann das schon. 8-) Man muss nur die headers/footers.inc.php anpassen.

Schon wieder ein Modul weniger zu pflegen. :mrgreen:

Bootswatch und Font Awesome folgen.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

So, Bootstrap, Bootswatch und Font Awesome sind erfolgreich verschoben. In der headers.inc.php

Bootstrap:
'CAT/vendor/twbs/bootstrap/dist/css/bootstrap.min.css'

Bootswatch (hier als Variante beim Backstrap Theme):
CAT/vendor/thomaspark/bootswatch/dist/'.$variant.'/bootstrap.min.css'

Font Awesome:
'CAT/vendor/fortawesome/font-awesome/css/font-awesome.min.css'

In der footers.inc.php

Bootstrap:
'CAT/vendor/twbs/bootstrap/dist/js/bootstrap.bundle.min.js',

Bei Bootswatch und Font Awesome gibt es keine Javascripts.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

...und da die wblib3 auch per Composer geladen wird...

https://packagist.org/packages/webbird/wblib3

*stolz* :mrgreen:
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

jQuery, jQueryUI und getID3 hat das gleiche Schicksal ereilt...

Edit: HTMLPurifier...
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
creativecat
Beiträge: 1430
Registriert: Mi 6. Feb 2013, 12:41
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von creativecat »

Du bist einfach.... der HAMMER!
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: Repositories - oder wie machen wir das mit BC2?

Beitrag von shadowcat »

Jetzt wird's spannend... DOCTRINE!

Edit: Och, das war easy. Frag mich nur warum da so viel mehr mitkommt als wir bisher im Modul hatten. Alles überflüssiges Zeugs. :lol:
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Antworten