[QUOTE=aggrosoft;31030]Das klingt ja alles schon gut, ich denke wenn wir diese beiden Module zu einem verbinden sind wir der Sache schon um einiges näher. Würdest du dich bereit erklären das ganze mit beizusteuern? Wenn ja dann häng doch mal ein bisschen code an.[/QUOTE]
… und die IP von den Server finde ich derzeit nicht. 
Denke auch besser per PM.
Komischerweise geht das oxid forum 
zum glück is das eine .com domain
Hier rufen heut im minuten takt die leute an wegen dem mist
[QUOTE=aggrosoft;30940]Hallo liebe Gemeinde,
Heute haben wir wieder mal ein kleines Goodie für die Community - und zwar eine komplette Modulverwaltung für den Oxid Shop. Derzeit ist es ja so dass alle Module manuell installiert werden müssen, also ungefähr so:
[ul]
[li]copy_this rüberkopieren[/li][li]changed_full manuell abgleichen[/li][li]SQL Befehle ausführen[/li][li]Module Eintragen[/li][/ul]
So nun stellt euch vor Ihr müsstet nur noch das Paket hochladen und den changed_full manuell abgleichen - das macht unser neuer Modulmanager für Oxid! Doch nicht nur das er bietet darüber hinaus auch noch eine komfortable Oberfläche um Moduleinträge zu pflegen (nicht diese schreckliche Texteingabebox). [B]Und das allerbeste an der Sache ist - er ist kostenlos[/B]!
Das ganze Paket ist noch zum Testen gedacht also nicht unbedingt für Live Shops und alle Module geeignet, die Modulverwaltung an sich funktioniert aber garantiert schon gut genug für live shops.
Das Archiv hänge ich an diesen Beitrag, wenn ein paar Leute es getestet und für gut befunden haben stelle ich das ganze in den Exchange (ja auch da als GPL for free).
Künftig werden alle unsere Module diesen Manager unterstützen sodass eine Modulinstallation nur noch den Bruchteil der Zeit benötigt.
Die Installation ist kinderleicht, einfach die Dateien auf den Server kopieren - den tmp Ordner leeren und schon kann es los gehen.
Viel Spaß damit,
euer Aggrosoft Team[/QUOTE]
Hallo in die Runde,
hab’s leider erst spät gelesen. Wir arbeiten auch seit geraumer Zeit an einer ähnlichen Sache. Der Ansatz war zwar ein Anderer, das Ergebnis kommt dem aber schon recht nahe:
Unsere Module benötigen häufig eigene Konfigurationsdaten. Daher haben wir diese über eine gemeinsame Klasse gekapselt. Nebenbei entstanden noch weitere Bibliotheken wie z.B. erweiterte Logging-Möglichkeiten. Nach einigen Versionskonflikten (teilweise sind bei den Modulen veraltete Versionen beigelegt, die sich gegenseitig überschrieben), haben wir die nun in ein “Modulframework” ausgelagert. Dieses kann sich online (per Knopfdruck) auf Aktualität prüfen und bei Bedarf selbst updaten.
Diese Updateschritte haben wir darin derzeit einsatzfähig:
Das Ganze ist ausbaubar, da sich die Installationsschritte an einer den Paketen beiliegenden XML-Datei orientieren. Bislang ist das auf die Bibliotheken unseres Frameworks ausgelegt. Geplant ist aber, damit auch Module installierbar und updatebar zu machen (hier scheitert’s tatsächlich noch an einer kundenfreundlichen (!) Lösung für die copy_this-Sachen)
Das Paket haben wir bei den ersten Modulen seit mehreren Wochen im Einsatz und stehen kurz davor, das auf die Öffentlichkeit loszulassen.
Wenn da Bedarf besteht: Wir haben da in den letzten Monaten eine Menge Erfahrungen gesammelt.
Meine güte, da haben wohl so einige Leute bereits Ansätze gemacht - schön das nicht nur wieder uns so etwas wünschen.
Also mal so generell in die Runde, wer hätte Lust seinen code in das Modul einfließen zu lassen? Ich denke soetwas wäre eine klassische GPL Sache wo auch alle an einem Strang ziehen müssen damit es sich durchsetzt. Wenn hier wieder jeder eine eigene Lösung raushaut dann endet das denke ich im Chaos.
[QUOTE=aggrosoft;31044]Meine güte, da haben wohl so einige Leute bereits Ansätze gemacht - schön das nicht nur wieder uns so etwas wünschen.
Also mal so generell in die Runde, wer hätte Lust seinen code in das Modul einfließen zu lassen? Ich denke soetwas wäre eine klassische GPL Sache wo auch alle an einem Strang ziehen müssen damit es sich durchsetzt. Wenn hier wieder jeder eine eigene Lösung raushaut dann endet das denke ich im Chaos.[/QUOTE]
Ich bin da für jede Tat offen.
Daniel würdest du deinen vorhandenen code einfach mal hier reinstellen, dann kann sich davon jeder mal ein Bild machen.
Also ich habe mich nochmal rangesetzt zwecks der changed_full Problematik und habe einen Diff Algorithmus dazu gepackt der einem auf einen Blick die Unterschiede zwischen neuer und alter File zeigen. Das hilft zwar nicht unbedingt beim einspielen aber man kann sich schonmal ein Bild machen ob die Unterschiede gravierend sind oder nicht. Man hat dann auch die Wahl ob man die Datei mit kopieren will - ich hänge mal 2 Screens an.
[QUOTE=aggrosoft;31047]Daniel würdest du deinen vorhandenen code einfach mal hier reinstellen, dann kann sich davon jeder mal ein Bild machen.[/QUOTE]
Wäre es da nicht sinnvoller, ein Projekt in oxidforge anzulegen?
Unser Quelltext wird noch ein paar Tage brauchen. Den muß ich erst mal aus dem jetzigen Kontext lösen; darin sind noch andere Komponenten verbaut, die damit Nichts zu tun haben. Sobald ich das extern lauffähig hab, stellen wir das zur Verfügung.
Soviel ich weiß, ist das angelegt und muss noch freigeschaltet werden.
Ja ich warte nur noch auf Freigabe, ich gebe bescheid wenn es soweit ist.
Ich habe jetzt mal mein erstes Modul für Oxid geschrieben und denke nicht das so ein Modul sinnvoll ist. Mann kann die Module so schreiben das der Nutzer zwei Schritte zu erledigen hat:
So viel Aufwand ist das nicht. Hierbei werden die Datenbank Einträge automatisch angelegt, die Language-Files eingebunden und das tmp Dir geleert.
Das einzige was meiner Meinung nach wirklich Sinnvoll ist:
Jedoch haben alle diese Erweiterungen nichts in einem Modul verloren sonder gehören in den Core.
Das heißt wohl auch dass dein Modul jedes mal aufs neue prüft ob die DB Einträge bereits gesetzt wurden? Wie soll denn diese Update Funktion aussehen? Warum soll man aus dem Admin Updaten aber nicht installieren können?
[QUOTE=GM_Alex;33525]Ich habe jetzt mal mein erstes Modul für Oxid geschrieben und denke nicht das so ein Modul sinnvoll ist. Mann kann die Module so schreiben das der Nutzer zwei Schritte zu erledigen hat:
So viel Aufwand ist das nicht. Hierbei werden die Datenbank Einträge automatisch angelegt, die Language-Files eingebunden und das tmp Dir geleert.[/QUOTE]
Wenn Du zig Erweiterungen anbietest, die jeweils mehrere Dateien und “Einbauanweisungen” enthalten, dann macht das sehr wohl Sinn…
Dann kann man nämlich “Packages” definieren und wesentlich einfacher verteilen…
[QUOTE=GM_Alex;33525]Das einzige was meiner Meinung nach wirklich Sinnvoll ist:
Die müssen nicht im “modules”-Ordner liegen, sondern können natürlich auch in (mehrstufigen) Unterstrukturen dazu gespeichert sein,
[QUOTE=GM_Alex;33525] 2. Aktivierung des Plugins nicht mehr über die Textzeilen sonder alla Modul aktivieren / deaktivieren. Hier würde sich ein Textfile anbieten in dem der Modulentwickler angibt was überschrieben wird. Also die Informationen die der User jetzt selbst eintragen muss eben in einer einfachen Textdatei.[/QUOTE]
Das fände ich auch besser, vor allem wenn die Software versuchen würde, auch mehrere solche Beschreibungs-Dateien anhand eines Namens-Musters zu erkennen und einzubinden (wie bei den Sprachdateien). Dann könnte man einfach seine eigenen Definitionsdateien dazu bringen.
Kostet allerdings wieder Performance…
[QUOTE=GM_Alex;33525]3. Update Funktion für Plugins aus dem Adminpanel heraus, ähnlich wie bei Wordpress.[/QUOTE]Verstehe ich nicht so ganz…
Ein Update wird ja einfach durch kopieren neuer Moduldateien erledigt?!
[QUOTE=aggrosoft;33541]Das heißt wohl auch dass dein Modul jedes mal aufs neue prüft ob die DB Einträge bereits gesetzt wurden?[/QUOTE]
Das vorhanden sein der Modul-DB wird geprüft wenn man die AdminView des Moduls aufruft. Ich denke nicht das ein “SHOW TABLE LIKE” einen wirklichen mehr Aufwand bedeutet und ein Performanceverlust zur Folge hat. Und das das Plugin ohne Datenbank den Shop nicht abschießt sondern einfach nicht angezeigt wird versteht sich ja von selbst.
[QUOTE=aggrosoft;33541]Wie soll denn diese Update Funktion aussehen?[/QUOTE]
Ich würde es mit Hilfe von OXID eXchange lösen. Die Plugin-Files werden hochgeladen, der Entwickler gibt die Version an und der Oxid Shop prüft ob eine neue Version da ist. Dann wird die neue Version gezogen und entpackt, Update Script laufen lassen, fertig. Schau dir einfach mal Wordpress an dann weist du was ich meine.
[QUOTE=aggrosoft;33541]Warum soll man aus dem Admin Updaten aber nicht installieren können?[/QUOTE]
Aktivieren / Installieren ist doch beides das gleiche. 
[QUOTE=avenger;33544]Wenn Du zig Erweiterungen anbietest, die jeweils mehrere Dateien und “Einbauanweisungen” enthalten, dann macht das sehr wohl Sinn…
Dann kann man nämlich “Packages” definieren und wesentlich einfacher verteilen…[/QUOTE]
Das mag sein, wie gesagt es ist mein erstes Modul für Oxid, und ehrlich gesagt denke ich noch nicht an Packages.
[QUOTE=avenger;33544]
Die müssen nicht im “modules”-Ordner liegen, sondern können natürlich auch in (mehrstufigen) Unterstrukturen dazu gespeichert sein,[/QUOTE]
Das stimmt so nicht ganz. Wenn du ein Object mit oxnew anlegen willst muss das File im modules Ordner liegen.
[QUOTE=avenger;33544]
Das fände ich auch besser, vor allem wenn die Software versuchen würde, auch mehrere solche Beschreibungs-Dateien anhand eines Namens-Musters zu erkennen und einzubinden (wie bei den Sprachdateien). Dann könnte man einfach seine eigenen Definitionsdateien dazu bringen.
Kostet allerdings wieder Performance…[/QUOTE]
Dürfte keine Performance kosten. Du liest das Textfile doch nur einmal aus und dann wird es, für den User nicht mehr sichtbar, genau wie jetzt auch eingetragen.
[QUOTE=avenger;33544]Verstehe ich nicht so ganz…
Ein Update wird ja einfach durch kopieren neuer Moduldateien erledigt?![/QUOTE]
Siehe Post davor.
Das stimmt so nicht ganz. Wenn du ein Object mit oxnew anlegen willst muss das File im modules Ordner liegen.
So werden Module ja nicht aktiviert…
Sondern wenn per “oxnew” eine OXID-Klasse aktiviert wird, dann wird geprüft, ob dafür ein “overload” definiert ist…
Und dieses “overload” kann dann irgendwo in der “modules”-Verzeichnisstruktur liegen.
Das ist also nur ein mögliches Problem für ganz neue Klassen, aber die kann man ja auch direkt in den “core”- oder “view”-Ordner kopieren, weil die ja durch Updates nicht gefährdet sind.
[QUOTE=avenger;33552]So werden Module ja nicht aktiviert…
Sondern wenn per “oxnew” eine OXID-Klasse aktiviert wird, dann wird geprüft, ob dafür ein “overload” definiert ist…
Und dieses “overload” kann dann irgendwo in der “modules”-Verzeichnisstruktur liegen.
Das ist also nur ein mögliches Problem für ganz neue Klassen, aber die kann man ja auch direkt in den “core”- oder “view”-Ordner kopieren, weil die ja durch Updates nicht gefährdet sind.[/QUOTE]
Das ist schon klar aber du willst ja, jedenfalls ich, Module einfach verwalten können. Und es ist einfach schöner wenn du alle benötigten Files unter “modules/YOURMODULE” hast. Dann gibt es auch kein “Kopiere x nach a, dann kopiere y nach b etc.” sondern “Kopiere alles nach modules und aktiviere das Modul, fertig.”. Wenn Module auf diese Art installiert werden können dann werden auch keine Installationsanleitungen mehr benötigt.
ich werfe mal ein böses wort in den raum: templates.
auch das kann man sauber lösen, aber viele module benötigen eingriffe in die template struktur, und diese sind nicht so einfach flexibel abbildbar da die struktur jedes shops komplett vom standard abweichen kann.
[QUOTE=GM_Alex;33554]Das ist schon klar aber du willst ja, jedenfalls ich, Module einfach verwalten können. Und es ist einfach schöner wenn du alle benötigten Files unter “modules/YOURMODULE” hast. Dann gibt es auch kein “Kopiere x nach a, dann kopiere y nach b etc.” sondern “Kopiere alles nach modules und aktiviere das Modul, fertig.”. Wenn Module auf diese Art installiert werden können dann werden auch keine Installationsanleitungen mehr benötigt.[/QUOTE]
Das ist doch auch kein Problem:
Dann legt man halt die Unterverzeichnisse an, und lässt alles in die Shop-Root kopieren…
[QUOTE=csimon;33559]ich werfe mal ein böses wort in den raum: templates.
auch das kann man sauber lösen, aber viele module benötigen eingriffe in die template struktur, und diese sind nicht so einfach flexibel abbildbar da die struktur jedes shops komplett vom standard abweichen kann.[/QUOTE]
Das Problem wirst du aber immer haben und ich denke das lohnt es auch nicht sich was super tolles einfallen zu lassen. Jede Lösung die ich in die Richtung bis jetzt gesehen habe war zwar gut gemeint aber nicht wirklich toll. Nehmen wir zum Beispiel mal das Widget System von Wordpress, da kannst zwar deine Module in Container ziehen aber vielleicht willst du sie auch mal an einer anderen Stell und das muss du dann wieder im Template machen. Wer einen professionellen Shop will der brauch halt auch einen Dienstleister der was davon versteht. Und ein WYSIWYG für Module halte ich für wenig sinnvoll da es nie wirklich funktionieren wird bzw. nie alle Szenarien abdecken kann.
[QUOTE=avenger;33560]Das ist doch auch kein Problem:
Dann legt man halt die Unterverzeichnisse an, und lässt alles in die Shop-Root kopieren…[/QUOTE]
Hm, auch eine Möglichkeit aber anders finde ich es einfach schöner. 