WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

AMASP und Download-Bereich

<< < (6/12) > >>

DarkViper:

--- Quote from: Stefek on January 09, 2014, 02:29:39 PM ---
--- Quote from: badknight on January 09, 2014, 11:14:57 AM ---Ok, hab nun mal nachgefragt:
Egtl. sollte die Vorgabe lauten:
Keine Module die in "fremde" Module eingreifen (Code verändern, etc.)
--
Abhängigkeiten sind kein Problem - nur müssen dies entsprechend gekennzeichnet werden.
--- End quote ---
Danke für die Klarstellung, Daniel.
Das macht viel mehr Sinn.
--- End quote ---

Ich versuchs mal etwas klarer zu stellen. ;)
In andere Module 'eingreifen' bedeutet im schlimmsten Fall, irgendetwas in das Verzeichnis eines anderen Moduls zu schreiben oder schreibend auf dessen Datenbanktabellen oder INI-dateien etc. zuzugreifen. (z.B. das wysiwyg-history Modul, das das originale wysiwyg-Modul verändert, dessen Tabellen schreibend benutzt und daher ohne erweitertes Wissen von normalen Usern nicht mehr deinstalliert werden kann).

Etwas einfacher aber oft nicht unkritisch ist eine einseitige Verbindung bei der ein Modul direkt Daten eines anderen Modules ausliest(nur lesen, nicht schreiben). Selbstverständlich funktioniert das zu dem Zeitpunkt, zu dem das gecoded wird einwandfrei. Was aber, wenn das abgefragte Modul im Zuge eines Upgrades verändert oder eventuell gar gelöscht wird? Meist hängen die Abfragen dann 'in der Luft' und das Script stürzt ab.
Wesentlich sinnvoller ist es da, mit dem anderen Autor/en Kontakt aufzunehmen und möglichst eine neutrale Schnittstelle zwischen den Modulen aufzubauen. Dann kann später jeder sein Modul nach Herzenslust ändern(solange die Schnittstelle unangetastet bleibt) ohne dass das jeweils andere Modul überhaupt was davon bemerkt und einfach weiterhin wie gewohnt funktioniert.

Schnittstellenlose Verbindungen: Sind absolut nicht gewünscht. Wer sie trotzdem aufbaut, ok. Aber er trägt auch das Risiko, dass sein Modul nach Updates etc. einfach nicht mehr funktioniert. Nennt man dann 'persönliches Pech'. ;-)

Generell: Auf Verbindungen/Abhängigkeiten zwischen Modulen muss unbedingt schon vor der Installation deutlich hingewiesen werden. Am Besten auch schon auf der jeweiligen Downloadseite. So kann jeder User selbst entscheiden, ob er evt. einen abhängigen Rattenschwanz von anderen Modulen auch noch installiert oder gleich verzichtet.

Stefek:

--- Quote from: DarkViper on January 09, 2014, 03:55:26 PM ---Generell: Auf Verbindungen/Abhängigkeiten zwischen Modulen muss unbedingt schon vor der Installation deutlich hingewiesen werden. Am Besten auch schon auf der jeweiligen Downloadseite. So kann jeder User selbst entscheiden, ob er evt. einen abhängigen Rattenschwanz von anderen Modulen auch noch installiert oder gleich verzichtet.

--- End quote ---
Ja, das muss sein. Die Repo sollte das aber hergeben. Z.B. ein Feld "Module Dependency" und wenn ja, dann mit der Möglichkeit, das Modul zu benennen, oder besser: zum Modul zu verlinken.



--- Quote from: DarkViper on January 09, 2014, 03:55:26 PM ---In andere Module 'eingreifen' bedeutet im schlimmsten Fall, irgendetwas in das Verzeichnis eines anderen Moduls zu schreiben oder schreibend auf dessen Datenbanktabellen oder INI-dateien etc. zuzugreifen.

--- End quote ---
Was aber, wenn eines der Module Tabellen zur Verfügung stellt, speziell für den Zweck, dass andere Module auf diese zugreifen?
Praktisches Beispiel: ein Kommentarmodul (nur als Beispiel) auf dessen Methoden mehrere, spätere Module, zugreifen können (eine bereitgestellte Klasse über den Autoloader), sowie in gemeinsame DB Tabellen schreiben (in diesem Falle {TABLE_PREFIX}mod_globalcomments_comments).

Ist es nicht so, dass eine uninstall.php ein phpScript ausführen kann, der dann, bevor ein Modul deinstalliert wird, auch eine Nachricht ausgiebt?

(Das sind theoretische Fragen mit einem praktischen Hintergrund, da ich nämlich im Moment an etwas arbeite, das in diese Richtung geht.)

Gruß,
Stefek

DarkViper:

--- Quote from: Stefek on January 09, 2014, 04:13:38 PM ---Was aber, wenn eines der Module Tabellen zur Verfügung stellt, speziell für den Zweck, dass andere Module auf diese zugreifen?
Praktisches Beispiel: ein Kommentarmodul (nur als Beispiel) auf dessen Methoden mehrere, spätere Module, zugreifen können (eine bereitgestellte Klasse über den Autoloader), sowie in gemeinsame DB Tabellen schreiben (in diesem Falle {TABLE_PREFIX}mod_globalcomments_comments).
--- End quote ---
Das ist der absolut klassische Fall für eine Schnittstelle in GlobalComments(auch mal API genannt) ;)

Dann genügt im abfragenden Modul beispielsweise die Simple Frage: (noch mit den Pseudo-Namespaces)

--- Code: ---<?php
if (class_exists('m_globalcomments_Api')) {
    // ist die Klasse noch nicht geladen, lädt sie der Autoloader
    $oGlobalCommentsApi = new m_globalcomments_Api();
} else {
    // sorry, da gibts kein API
}

--- End code ---
Der Vorteil: Irgendwann passt GlobalComments evt. mal nicht mehr und wird umgebaut. Auch die Tabellenstruktur kann sich ändern.
Wird jetzt eine Schnittstelle benutzt, ändert sich für alle Module die darauf zugreifen praktisch nichts. Nur die 'innere' Seite der Schnittstelle muss auf die Änderungen angepasst werden.
Wenn ein Modul der Schnittstelle sagt: 'gib mir das und das... oder schreibe das..' dann spricht es nur die konstante Schnittstelle an. Wie die Daten innerhalb von GlobalComments verarbeitet, geschrieben oder gesucht werden, interessiert ein anderes Modul dann nicht im Geringsten.

Ist wie mit PHP-Befehlen..  Du schreibst deinen Funktionsaufruf und erwartest ein bestimmtes Ergebnis. Wie die Funktion das macht, ist Dir wurst. Ändert PHP in seinem Code mal was... interessiert es Dich nicht, solange der Funktionsaufruf weiterhin das selbe Ergebnis bringt.


--- Quote from: Stefek on January 09, 2014, 04:13:38 PM ---Ist es nicht so, dass eine uninstall.php ein phpScript ausführen kann, der dann, bevor ein Modul deinstalliert wird, auch eine Nachricht ausgiebt?
--- End quote ---
Das kann in der uninstall.php des jeweiligen Modules passieren.

fischstäbchenbrenner:
Arbeitskreis ist immer super!

Ich denke: zuerst sollte man versuchen, das AMASP wiederzubeleben. Das AMASP ist bekannt und im Grunde ja auch richtig.
Erst wenn das nicht geht - warum auch immer - sollte man eine alternative Lösung andenken.

Stefek:
@DarkViper
ja, genau so ist das gedacht und geplant.

Bezüglich "offizielle Repo", wer ist denn da Ansprechspartner? Ich weiß nur, dass Ruud es programmiert hatte.
Ich denke, sowas sollte im getrennten Thread besprochen werden.
Wir brauchen auf jeden Fall einige feste Spielregeln (Richtlinien, wenn man so will).

@Private Repos a lá AMASP und Co
generell ist nichts dagegen einzuwenden ALLE WB Bezogenen Module irgendwo abzulegen.
Wer da Lust hat, sollte sich nicht abhalten lassen.
Im Grunde denke ich, alles was die Nutzung und Verbreitung von WebsiteBaker vermehrt, sollte nicht gestoppt werden.
Ob AMASP es ist, oder jemand anderes es besser kann steht sicher nicht in den Sternen geschrieben und wird nur dadurch bestimmt, ob sich jemand dessen annimmt.

Ein "offizielles Repo" sollte dennoch so gemanaged sein, dass Autoren leichter mitmachen können ohne zu viele wenig Sinn ergebende Spielregeln beachten zu müßen. Die logischen Spielregeln ergeben sich quasi von selbst und wenn sie festgeschrieben sind, um so besser.

Gruß,
Stefek

Navigation

[0] Message Index

[#] Next page

[*] Previous page