Modularer Aufbau - Unclassified NewsBoard

Netsurfer

2008-04-07, 01:11 #1

Member since Nov 2007 · 2 posts
Group memberships: Members

Show profile ·

Link to this post

Subject: Modularer Aufbau

Hallo!

Ich möchte hier auch mal ein paar Gedanken & Überlegungen loswerden ;-)

.

Eins der Hauptprobleme bei vielen Skripten im Bereich Wikis, Foren, CMS, etc. sehe ich vor allem darin, dass sie nicht wirklich modular aufgebaut sind. Das erschwert eigentlich immer die Integration in bereits vorhandene Anwendungen, sowie mögliche Anpassungen an eigene Erfordernisse und Wünsche.

Was ich meine ist, dass man bspw. das Foren-Skript in möglichst viele kleine Module "zerlegen" sollte.
Jedes dieser Module müsste über verschiedene Meta-Daten verfügen, die z.B. Auskunft darüber geben

welche Abhängigkeiten es zu anderen Modulen gibt

welche Variablen zwingend erwartet und zurückgegeben werden, und welche optional

ob es sich um ein "Core-Modul" handelt, oder ob es optional ist

Ich möchte das mal anhand eines abstrakten Beispiels verdeutlichen:
Angenommen wir haben eine Kiste mit farbigen Bauklötzen. Aus diesen wollen wir nun einen Turm bauen. Unser Turm muss aus mind. 5 Klötzen bestehen. Nehmen wir mal an, das seien 1 x Rot, 1 x Grün, 1 x Blau, 1 x Gelb und 1 x Schwarz. Diese stellen also quasi die "Default Core-Moduls" dar, die vorhanden sein müssen.

Optional könnten wir jetzt aber auch noch beliebig viele andere Klötze mit einfügen.

Wenn mir jetzt aber bspw. das "Verhalten" des roten Default-Klotzes nicht gefällt, dann könnte ich ihn auch durch einen anderen Klotz ersetzen.

Die jeweilige Konfiguration der einzelnen Module könnte man zentral in einer Konfigurations-Seite verwalten und administrieren.

Für die benötigten Variablen, bzw. die entsprechenden Rückgabewerte des jeweiligen Moduls müsste man die Module zusätzlich noch mit einer Art "Übersetzer/ Translator" versehen, der die verschiedenen Variablen (aus den verschiedenen anderen Anwendungen) quasi "angleicht" - also hin und zurück jeweils so umwandelt, dass die jeweilige Anwendung oder ein anderes Modul diese versteht.

Was könnten/ sollten mögliche Module sein?
Nun, die Authentifizierung wäre bspw. ein separates Modul. Oder der BBCode-Parser, oder die Suche, das Tagging-System, u.v.m.

Nur wenn es gelingt, ein trotz der Aufteilung auf viele kleine Module, noch sehr effizient arbeitendes Skript zu programmieren, hat man hinterher eine in allen Bereichen sehr anpassungsfähige Anwendung.

Nur so ein Gedanke ... .

Gruß
Gunther

Yves (Administrator) 2008-04-07, 01:59 #2

User title: UNB developer & webmaster
Member since Jan 2004 · 3814 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Hallo Gunther,

ja, das ist in der Tat eine sehr wünschenswerte Sache. Kannst du anstelle der Bauklötze auch "echtere" Codebeispiele oder technische Konzepte als Beispiele angeben?

So ein System aus vielen kleinen, austauschbaren und möglichst noch durch einen DAU konfigurierbaren Modulen wird nämlich leider sehr schnell sehr komplex. Die Kosten einer solchen Verwaltung übersteigen dann schnell die, die man hat, wenn man auf den ganzen Modulkram verzichtet und einfach den ganzen statischen Rest reinlädt.

Außerdem war meine Idee diesmal sowieso, sehr viel weniger Konfiguration an die Oberfläche zu bringen. Denn schauen wir doch mal, wer braucht denn die Möglichkeiten, einzelne Code-Module auszutauschen und Funktionen ein- und auszubauen oder Funktionen in Webseiten zu integrieren? Das ist der Webmaster/Webdesigner, also der, der sowieso mit den einzelnen Webseiten-Dateien arbeitet. Der braucht kein Web-UI, über das er irgendwas konfiguriert. Der will eine Datei nehmen und in eine andere "einfügen" (oder referenzieren, etc.), sodass die gewünschte Funktion dann an der passenden Stelle an der Oberfläche erscheint. Solche Konfigurationsoptionen wie ob das Anmeldeformular oben oder unten angezeigt wird, entfallen dann komplett. Es wird dort angezeigt, wo der Webdesigner es hingesetzt hat. U.a. ist die gesamte Verwaltung mehrerer Designs überflüssig: Der Webdesigner erstellt ein Design, das zu seiner Seite passt, und das ist es dann. Fertige Forenkomplexe, für die man keinerlei Programmierkenntnisse mitbringen muss/darf, die man aber auch nirgendwo einbauen kann, gibt es schon zuhauf, UNB1 inklusive, ehrlich gesagt. (Dieses Ziel habe ich bisher noch nicht zufriedenstellend erreicht.) Demnach möchte ich mich dieses Mal eigentlich mehr an Entwickler wenden. Die sollen die Möglichkeit erhalten, ihre eigenen Webseiten und Webanwendungen einfach um Kommunikationsfunktionen zu erweitern, ohne sich um Sessions, Benutzer oder Datenbanken kümmern zu müssen.

(Davon unbeeinflusst bleibt natürlich die Absicht, auf Basis dieser UNB-Komponenten eine Forenanwendung zu entwickeln und zu veröffentlichen, die für sich wieder als mehr oder weniger konventionelles Webforum eingesetzt werden kann. Die Vorteile der Code-Konfiguration bleiben aber Entwicklern vorbehalten. Diese Anwendung dient auch als Anwendungsbeispiel der UNB-Komponenten.)

Unter diesen Bedingungen sieht ein modularer Aufbau einer Software wahrscheinlich etwa objektorientiert aus, wobei einzelne Klassen eben verwendet werden oder nicht, oder durch eigene Klassen ausgetauscht werden.

Dann bleibt natürlich noch zu klären, welche Funktionen von dieser Modularität betroffen sein sollen. Und zwar Kernfunktionen sowie mögliche spätere Erweiterungen. Da meine aktuelle Funktionsliste noch nicht sehr lang ist, fehlen mir da noch die Beispiele.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Netsurfer

2008-04-07, 18:20 #3

Member since Nov 2007 · 2 posts
Group memberships: Members

Show profile ·

Link to this post

Hallo Yves!

Quote by Yves:
Hallo Gunther,

ja, das ist in der Tat eine sehr wünschenswerte Sache. Kannst du anstelle der Bauklötze auch "echtere" Codebeispiele oder technische Konzepte als Beispiele angeben?

Ich werd's versuchen :-)

.
Ich stelle mir das in etwa so vor:
Bei einem vollständig modularen Aufbau, gibt es ja dann verschiedene Arten von Modulen

zwingend notwendige Module ("Core-Moduls")

optionale Module (also Erweiterungen oder Plug-Ins)

Alle zwingend erforderlichen Module müssen natürlich in einer "Default-Version" vorhanden sein, damit die Anwendung auch ohne irgendwelche Änderungen voll funktionsfähig ist.

Da der Haupt-Sinn von Modulen ja darin besteht, dass ich sie auswechseln kann, kommt hier also das nächste "Modul-Kriterium" ins Spiel - nämlich die Abhängigkeiten, bzw. das sich gegenseitige Ausschließen von Modulen.

Beispiel:
Als Beispiel fällt mir da das mögliche "Datenbank-Modul" ein. Das entsprechende Core-Modul könnte so bspw. rein auf MySQL beschränkt sein. Zusätzlich könnte es dann Module für andere DBMS geben, wie z.B. PostgreSQL. Von diesen Modulen dürfte dann immer nur eins "aktiv" sein.

Grundsätzlich muss man sich natürlich im Vorfeld entscheiden, welche Funktionalitäten man in ein bestimmtes Modul integrieren will, bzw. für welche man eigenständige Module anlegt. Um bei dem gewählten Beispiel zu bleiben, könnte man natürlich ebensogut diverse DBMS in ein, dann allerdings wieder sehr komplexes) DB-Modul packen, mit einer entsprechenden Auswahlmöglichkeit in den Konfigurationseinstellungen.

So ein System aus vielen kleinen, austauschbaren und möglichst noch durch einen DAU konfigurierbaren Modulen wird nämlich leider sehr schnell sehr komplex. Die Kosten einer solchen Verwaltung übersteigen dann schnell die, die man hat, wenn man auf den ganzen Modulkram verzichtet und einfach den ganzen statischen Rest reinlädt.

Nein - DAU-sicher geht eh nie! Dazu sind die Menschen zu einfallsreich ;-)

.
Eine einzige Konfigurationsseite würde aber ja ausreichen. Dort wären alle Core-Module aufgelistet, also die, die zwingend vorhanden sein müssen. Dazu gäbe es zu jedem Modul eine entsprechende Auswahlmöglichkeit, welches Modul, von den jeweils vorhandenen/ installierten, verwendet werden soll. Daraus würden die jeweiligen Abhängigkeiten ermittelt, und dem Admin signalisiert, ob noch Module fehlen, oder die Anwendung vollständig konfiguriert ist (quasi ein ähnliches System wie bspw. bei den Debian Paketen).

Außerdem war meine Idee diesmal sowieso, sehr viel weniger Konfiguration an die Oberfläche zu bringen. Denn schauen wir doch mal, wer braucht denn die Möglichkeiten, einzelne Code-Module auszutauschen und Funktionen ein- und auszubauen oder Funktionen in Webseiten zu integrieren? Das ist der Webmaster/Webdesigner, also der, der sowieso mit den einzelnen Webseiten-Dateien arbeitet. Der braucht kein Web-UI, über das er irgendwas konfiguriert. Der will eine Datei nehmen und in eine andere "einfügen" (oder referenzieren, etc.), sodass die gewünschte Funktion dann an der passenden Stelle an der Oberfläche erscheint. Solche Konfigurationsoptionen wie ob das Anmeldeformular oben oder unten angezeigt wird, entfallen dann komplett. Es wird dort angezeigt, wo der Webdesigner es hingesetzt hat. U.a. ist die gesamte Verwaltung mehrerer Designs überflüssig: Der Webdesigner erstellt ein Design, das zu seiner Seite passt, und das ist es dann. Fertige Forenkomplexe, für die man keinerlei Programmierkenntnisse mitbringen muss/darf, die man aber auch nirgendwo einbauen kann, gibt es schon zuhauf, UNB1 inklusive, ehrlich gesagt. (Dieses Ziel habe ich bisher noch nicht zufriedenstellend erreicht.) Demnach möchte ich mich dieses Mal eigentlich mehr an Entwickler wenden. Die sollen die Möglichkeit erhalten, ihre eigenen Webseiten und Webanwendungen einfach um Kommunikationsfunktionen zu erweitern, ohne sich um Sessions, Benutzer oder Datenbanken kümmern zu müssen.

Ja genau! Deshalb sehe ich es auch nicht als sinnvolles Ziel an, wenn du versuchst die Funktionalitäten von Wikis oder CMS in das UNB2 zu integrieren. Vielmehr sollte sich das UNB2 so einfach wie möglich in solch bestehende Systeme integrieren lassen, und das mit einer möglichst flexiblen Anpassung im Bereich seiner eigenen Funktionalitäten.

(Davon unbeeinflusst bleibt natürlich die Absicht, auf Basis dieser UNB-Komponenten eine Forenanwendung zu entwickeln und zu veröffentlichen, die für sich wieder als mehr oder weniger konventionelles Webforum eingesetzt werden kann. Die Vorteile der Code-Konfiguration bleiben aber Entwicklern vorbehalten. Diese Anwendung dient auch als Anwendungsbeispiel der UNB-Komponenten.)

Das ist ja gewährleistet, dadurch das für jedes Modul eine Default-Version vorhanden ist.

Unter diesen Bedingungen sieht ein modularer Aufbau einer Software wahrscheinlich etwa objektorientiert aus, wobei einzelne Klassen eben verwendet werden oder nicht, oder durch eigene Klassen ausgetauscht werden.

Hier kann ich leider nur sehr begrenzt mitreden, da mein Wissen im Bereich OOP doch sehr gering ist :-(

Dann bleibt natürlich noch zu klären, welche Funktionen von dieser Modularität betroffen sein sollen. Und zwar Kernfunktionen sowie mögliche spätere Erweiterungen. Da meine aktuelle Funktionsliste noch nicht sehr lang ist, fehlen mir da noch die Beispiele.

Richtig! Das ist natürlich sozusagen die eigentliche "Kernfrage". Denn davon hängt nachher in erster Linie ab, wie anpassungsfähig die Anwendung tatsächlich ist.

Hier mal in loser Reihenfolge einige Aspekte, die mir jetzt spontan einfallen:

Authentifizierung (extern/ intern) - bei intern, wie?

DB-System

Darstellung (Forum, Board, einfach linear)

Funktionalität (Forum, nur Kommentarfunktion)

Strukturierung (klass. Forensystem, Tagging, Kategorien)

Gruß
Gunther

Yves (Administrator) 2008-04-07, 22:09 #4

User title: UNB developer & webmaster
Member since Jan 2004 · 3814 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Quote by Netsurfer:
Als Beispiel fällt mir da das mögliche "Datenbank-Modul" ein. Das entsprechende Core-Modul könnte so bspw. rein auf MySQL beschränkt sein. Zusätzlich könnte es dann Module für andere DBMS geben, wie z.B. PostgreSQL. Von diesen Modulen dürfte dann immer nur eins "aktiv" sein.

In der aktuellen Codebasis werden durch PHP-PDO bereits mehrere DBMS unterstützt. Dieses Beispiel fällt also schonmal raus.

Deshalb sehe ich es auch nicht als sinnvolles Ziel an, wenn du versuchst die Funktionalitäten von Wikis oder CMS in das UNB2 zu integrieren. Vielmehr sollte sich das UNB2 so einfach wie möglich in solch bestehende Systeme integrieren lassen, und das mit einer möglichst flexiblen Anpassung im Bereich seiner eigenen Funktionalitäten.

Die "Wiki- und CMS-Funktionen" sind auch nicht separat als solche zu identifizieren und einzeln zu entfernen. Es sind hier vielmehr die zugrunde liegenden Konzepte der Datenverwaltung, die UNB2 intern verwendet. So werden einzelne Mitteilungen bei einer Änderung z.B. nicht (zwangsläufig) überschrieben, sondern in einer neuen Version abgelegt. Außerdem lassen sich Mitteilungen Seitennamen zuordnen, unter denen sie direkt per URL abrufbar sind. Diese Dinge sind bereits ganz unten in der Datenstruktur verankert. Das einzige was man nicht verwenden muss, sind typische UI-Funktionen wie "Wer verweist auf diese Seite", "Recent Changes", "Versionen vergleichen" etc. Aber die kann der Webmaster ja mit den üblichen Template-Methoden nach belieben einfügen oder entfernen.

Unter diesen Bedingungen sieht ein modularer Aufbau einer Software wahrscheinlich etwa objektorientiert aus, wobei einzelne Klassen eben verwendet werden oder nicht, oder durch eigene Klassen ausgetauscht werden.
Hier kann ich leider nur sehr begrenzt mitreden, da mein Wissen im Bereich OOP doch sehr gering ist .

Oh, OOP-Kenntnisse wären für eine solche Diskussion aber schon sehr nützlich, wo doch die gesamte Anwendung vollständig objektorientiert aufgebaut ist. Im Gegensatz zum UNB1, das nur hier und da ein paar Klassen verwendet, gibt es in der aktuellen UNB2-Version keine einzige globale Funktion oder Variable. Und das sollte auch so bleiben. Allerdings werden Vererbung und Schnittstellen noch nicht genutzt, mangels Anwendungen. Module könnten aber so eine Anwendung dafür sein.

Hier mal in loser Reihenfolge einige Aspekte, die mir jetzt spontan einfallen:

Authentifizierung (extern/ intern) - bei intern, wie?

Ja, das wäre eine Möglichkeit, bei der ich mir Modulunterstützung vorstellen kann. Es gibt hier ja sehr unterschiedliche Verfahren (Username+Password, OpenId, InfoCard, LDAP, NTLM, Shared Session uvm.) und gerade für die Integration in bestehende Anwendungen mit ihrer eigenen Benutzerbasis ist diese Funktionalität wichtig.

DB-System

Bereits erledigt, siehe oben.

Darstellung (Forum, Board, einfach linear)

Funktionalität (Forum, nur Kommentarfunktion)

Der dem Benutzer angebotene Funktionsumfang wird durch die Anzeige der entsprechenden Formulare und Links in den Templates festgelegt. Wo kommen hier Module zum Einsatz?

Strukturierung (klass. Forensystem, Tagging, Kategorien)

Tags. Das ist eine der Grundannahmen des UNB2. Alles andere lässt sich in der Oberfläche damit abbilden.

Ich füge folgende Ideen an:

Markup-Parser (einen stelle ich zur Verfügung, andere ermöglichen vllt. HTML-Editoren, BBCode usw.)

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

This post was edited on 2008-04-07, 22:13 by Yves.