OpenPHPNuke - das Open Source CMS

Autor

Freespacer

Datum

07.12.2006 17:15

Beiträge:

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Entwickler X schreibt ein Modul das Teile von Entwickler Y braucht oder gebrauchen kann. X würde also Hard in den Code den Namen des Moduls von Y schreiben. Soweit unkritisch weil der Name sich nicht so ohne weiteres ändert. Aber nach deiner angaben würde er auch eine Download URL angeben. Und ge-nau da fängt es an. Download URLs und Versionen ändern sich ständig. Einig Y könnte da immer die Richtigen Daten haben. Nur wie sollte er die Hard im Code von X fest verankerten Daten denn ändern? Kann er ja nicht. Also ist dieser Weg so schon nicht akzeptabel.

Hm... Da gebe ich dir nur teilweise recht.

Ist alles schön und gut. Aber vergisst du nicht etwas entscheidendes? Wenn Modul X von Modul Y die Version 1.1 benötigt. Wie du so schön sagst, dass Modul Y hat seine Version aber 2.0 erhalten. Dann sagt es doch im Prinzip aus. Das Modul X bisher mit Modul Y Vers. 1.1 einwandfrei läuft, aber Modul Y mit Version 2.0 nicht angepasst wurde (Braucht nur ein Funktionsname im Modul Y sich ändern).

Daher auch Hardcoded wegen der Kompatibilität unter den Modulen, weil der Entwickler von X weiß, dass sein Modul X mit Modul Y Vers. 1.1 läuft.

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Einzige Lösung: Benutzung einer Externen Quelle um genau diese Daten zuhalten. Also du hat Irgendwo eine Zentrale Stelle in der Y sein Modul Registriert und die Daten Pflegt. X sagt in seinem Code nur dass er Modul Y braucht und erhält dann von der Zentralen Stelle die gewünschten Daten.

Wäre eher für den Entwickler gedacht, wenn das NEED- oder HAVETONICE-Modul sich geändert hat, dass automatisch eine Mail an den Entwickler geht sein Modul doch bitte anzupassen. Aber was mit dem Hardcoded angeht, habe ich schon dazu etwas geschrieben.

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Dabei muss man natürlich einiges Beachten damit es eben zu keinem Problem (wie du sagtest) kommt. Diese Zentrale Stelle kann durchaus auch nur ein Knoten sein. So das auch andere Knoten existieren können die sich halt unter einander austauschen. Wenn Y seine Daten nicht mehr Pflegt kann es eine Automatik geben die Y informiert zu sagen was den nu ist und das Y Modul auf obsolet setzt. Natürlich würde das X dann ebenfalls Informiert und sein Modul, ist ja dann auch eingetragen, würde eben so auf obsolet gesetzt werden. Hier läst sich noch viel einplanen bzw. machen.

Die Datenbank soll das Modul X, dass obsolet ist, dass andere Modul Y auch ausschalten? Da muss man wirklich Versionsprüfung betreiben, dann können unter umständen auch alte Modul laufen, wenn diese untereinander gebrauchen werden, aber nicht von einem Modul, der das neuste vom neusten Modul benötigt.

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Von daher sehe ich nicht das Problem in einer Zentralen DB die ja nicht mal so Zentral ist bzw. sein muss.

Hä? Eine zentrale Datenbank, die nicht zentral ist?! Äh.... Meinst du etwa eine Peer2Peer-Datenbank???

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Nur wie gesagt z.Zt. gibt es da keine extern Freien Module die das Benötigen würden.

Doch wird es demnächst geben.

stefan schrieb am 06.12.2006 um 08:12:06 Uhr folgendes:

Ich hoffe das ganze ist jetzt etwas Klarer.

Klar, bis auf einige Sachen.

Gruß

Sebastian