Es folgt eine wirre Sammlung an Gedanken zum Thema Module/Plugins. Ideen und Ratschläge sind stets herzlich willkommen!
Ein Modul betseht aus einer Menge von Klassen, die Aufgaben aus einem Bestimmten Bereich übernehmen sollen. Beispiele:
- HTTP: CRUD von Virtual Hosts, sperren von VirtualHosts, CRUD von Subdomains, Zuweisung von Domains zu VirtualHosts, setzen von Zugriff-Limits (Quota)
- FTP: CRUD von FTP-Accounts, setzen von Quota
- Benutzerverwaltung ...
Fragen:
- Soll jedes Modul Zugriff haben auf sämtliche in der gesamten Software bestehenden Models/Controller?
- Welche Authorisierungs-Methoden braucht jedes Modul?
- Welche Module müssen einander kennen?
- Welche Module sind voneinander abhängig?
- Macht es Sinn, abhängige Module zu gestalten, oder ist das ein Zeichen für schlechte Aufgabentrennung?
- Lassen sich alle Aufgabenbereiche überhaupt so genau abgrenzen? [s. erste Frage]
- Sollen Module aus Benutzer-, Administrator- oder Entwicklersicht erstellt werden? Ein Benutzer sieht den Unteschied zwischen einer "Domain", einem "VirtualHost" und einem "FTP-Account" vielleicht nicht (=> möglichst einfaches Interface, gutes Maß an Abstraktion der darunterliegenden Technologien/Anwendungen, hohes Maß an Automatisierung und sinnvolle Default-Werte). Ein Administrator sollte (?) jedoch tiefergehende Möglichkeiten haben und auf Applikationsebene Einstellungen vornehmen können (=> möglichst viele Einstellungsmöglichkeiten, auch auf Technischer Ebene). Ein Entwickler benötigt hingegen eine streng abgegrenzte Schnittstelle auf Code-Ebene, betrachtet "das Model Domain" und "das Model VirtualHost" als Datenbankentitäten usw. (=> ?????)
- Module sollen natürlich (?) bei der Installation keine Änderungen an anderen Modulen vornehmen dürfen. Um eine gute Erweiterbarkeit der Funktionalität bei stark vernetzten Modulen zu gewährleisten, müsste man Gebrauch machen von Callback-Funktionen. Rails bietet hierzu ein hervorragendes Mittel: Filter-Funktionen. Beispielsweise kann man Filter-Objekte (oder Methoden, Procs, ...) bauen, die vor, nach, oder um Methoden herum aufgerufen werden (also davor und danach), oder den Aufruf einer Funktion gänzlich ersetzen oder verhindern. So könnte ein Modul ein Callback-Objekt bei einem anderen Modul registrieren (z.B. für Authentifikationsaufgaben). Solche Möglichkeiten müssten in der API gut dokumentiert werden.
