Hallo,

ich bastel in meiner Freizeit immer noch ein meinem Mini-CMS. Nur leider kann ich mich nicht so recht für ein Design-Pattern entscheiden und will das ganze auch nicht irgendwo reinquetschen, zumal es nur wenige Funktionen besitzt (dachte zu erst an MVC).

Was ich aber ganz toll finden würde, ist die Möglichkeit, die Perl-Module auch wirklich als eigenständige Module zu verwenden, um so spätere Funktionen ohne Probleme einbinden zu können.

Beispiel: Es gibt ein extra Modul, mit dem man Mails verschicken kann. Das CMS selbst weiß weder, dass dieses Modul existiert, noch wie es funktioniert (okay, es weiß schon, dass es ein Modul "Mail" gibt, welches automatisch eingebunden wird). ;)

Wenn der Nutzer nun die URL index.cgi?module=mail&action=send plus POST-Parameter aufruft (ja, ich weiß, GET plus POST gleichzeitig macht man normalerweise nicht), wird ein Objekt von Mail erstellt und die Methode send mit den POST-Parametern aufgerufen.

Lange Frage kurzer Sinn: Ist dies überhaupt eine vernünftige Herangehensweise? Was würdet ihr besser oder ganz anders machen?

Hallo Lightman

Du kannst Mittels eval überprüfen ob ein Modul existiert und wenn dies der Fall ist, dieses zur Laufzeit mit Hilfe von require einbinden.
Dabei kannst du dann auch die entsprechenden Parameter für das Modul übergeben.

Beispiel:


Allerdings muss ich ehrlich sagen, dass ich gewaltig Bauchschmerzen habe, wenn man wie von dir geplant in einem CMS von außen beliebige Module nachladen kann. Gibt es doch auch einige Standartmodule, mit denen man gewaltigen Schaden (Dateien und Verzeichnisse löschen, Zugriff aufs System ...) anrichten kann.

Sinnvoller wäre eine Schnittstelle innerhalb des CMS, über das der Admin zusätzliche Module einbinden kann, welche nicht von außen erreichbar ist. ZB. mit einer Config Datei.

Hallo frankes.

Sowas habe ich mir auch gedacht. Entweder man inkludiert die Module via Config-Datei oder import sie aus einem extra Verzeichnis (so dass alle Module in diesem Verzeichnis eingebunden werden). Bei Weblog-Systemen wie z.B. WordPress wird es ja auch so ähnlich gemacht, über die Sicherheit würde ich mir da in erster Linie keine Sorgen machen (entsprechende Systeme und Schranken würde ich natürlich einbauen, dass man keinen Schaden anrichten kann).

Würdet ihr das für ein gutes Entwurfsmuster halten, oder sollte ich lieber auf z.B. MVC zurückgreifen? Was spricht dafür und dagegen? (aus eurer Sicht als erfahrende Perl'ianer)

Kann man die CMS-Teile die schon existieren irgendwo "besichtigen" i.S.v. ausprobieren? Bin allgemein am Thema CMS interessiert. Auch deshalb, weil CMS-Skripte wie kaum anderes so unterschiedlich sind in Ansätzen und Vorgehensweisen. Welche Features soll Dein CMS bekommen?

Das CMS hatte ich bereits vor ein paar Jahren in PHP geschrieben, aber eher unsauber gelöst, weshalb ich es in Perl neuschreiben möchte. Viele Sachen funktionieren deshalb z.Z. nur experimentell und sind nicht wirklich fertig (zumal ich neben dem Studium kaum Zeit dafür finde).

Wie gesagt, es ist ein kleines CMS. Folgende Module sind in der Rohform vorhanden: Param-Parser (für POST & GET, später noch COOKIE), Config (d.h. Config-Datei einlesen, z.B. mit Datenbank-Informationen), Template (Vorlagen parsen), Mail (E-Mails versenden), Database (Datenbank-Klasse um Verbindungen herzustellen und Queries zu prepare'n). Sind aber nur ein paar Basis-Methoden vorhanden, man kann also nicht viel mit anfangen, außer es zu testen.

Folgende Sachen fehlen noch: Sessions, Login, Administrations-Oberfläche, Datei-Upload, RSS, das ganze Frontend.

Obwohl der Thread schon etwas alt ist, muss ich etwas zur Sicherheit anmerken.

[quote=frankes,05.05.2007, 21:15]

Allerdings muss ich ehrlich sagen, dass ich gewaltig Bauchschmerzen habe, wenn man wie von dir geplant in einem CMS von außen beliebige Module nachladen kann.
[/quote]
Die Bauchschmerzen bekommst du ganz zu recht, denn wenn der Inhalt von $modul (ungeprüft) von außen kommt, ist der Code oben reinster Selbstmord.  Wenn ich als Benutzer z.B. die folgende URL übergebe (analog zu dem, was Lightman als Beispiel für mail genannt hatte):

dann ergibt das folgenden Code:

Da hat der Webserver evtl. ein Problem.

Wenn du ohnehin ein require $modul.'.pm' nach dem String-eval machst, dann wäre doch ein Block-eval der bessere Ersatz:

Das ist zumindest etwas sicherer als das String-eval.
Trotzdem würde ich eine Konfigurationsdatei bevorzugen.

Und, Lightman: -T nicht vergessen!

Noch etwas allgemeines:

[quote=Lightman,05.05.2007, 23:42]Folgende Module sind in der Rohform vorhanden: Param-Parser (für POST & GET, später noch COOKIE), Config (d.h. Config-Datei einlesen, z.B. mit Datenbank-Informationen), Template (Vorlagen parsen), Mail (E-Mails versenden), Database (Datenbank-Klasse um Verbindungen herzustellen und Queries zu prepare'n).[/quote]

Das hört sich nach Aufgaben für sehr verbreitete Module an:
Param-Parser => CGI.pm
Config => Config::Simple, Config::Any, Config::IniFiles, ...
Template => HTML::Template::Compiled, Template-Toolkit, ...
Database => DBI.pm

Ich hoffe mal, dass du auch jeweils Module eingesetzt hast.

Und für Mail-Versand gibt es auch sehr gute Module wie MIME::Lite oder Mail::Sender. Zu letzterem gibt es in unserem Wiki auch einen Artikel.