|
|
|
|
|
<wdss> konkret |
 |
Das <wdss>, ein Content-Management-System, welches den Inhalt anfaßt,
wie Sie es selbst auch tun.
Technische Einführung
Bedingungen:
- Die Redakteure müssen möglichst einfach Inhalte
hinzufügen, ändern und löschen können.
- Die Redakteure sollen sich nur wenig Gedanken über
das Layout machen müssen.
- Es sollen möglichst wenig Einschänkungen im
praktischen Gebrauch auftreten, z.B. sollen Newstexte nicht auf wenige 100 Zeichen beschränkt
sein.
-
Die selben Inhalte sollen auf verschiedene Weise auf verschiedenen Seiten
ausgegeben werden.
-
Das Layout der Site soll unabhängig von den Inhalten verwaltet werden
können.
-
Das Layout der Seiten einer Site sollen durch wenige Templates festgelegt
werden können.
-
Die Seiten sollen von Suchmaschienen indizierbar sein.
-
Die URLs der Seiten sollen in etwa denen von statischen Sites entsprechen
-
Die Konzeption und Realisierung einer Site soll einfach und wiederverwendbar
sein.
-
Spezielle Datentypen sollen einfach entwickelt werden können.
-
Es sollen auch mittlere Sites verwaltet werden können - mehrere 100
Seiten mit mehreren 1000 Inhalten.
Konsequenzen für die Konzeption und Realisierung:
-
Es muß ein Framework Administrationstool existieren, das die
Verwaltung der Daten übernimmt.
-
Das Framework muß objektorientierte Strukturen, oder anderweitig
wiederverwendbare Strukturen unterstützen.
-
Es muß eine Datenbank genutzt werden, die komplexe Datenstrukturen
indizierbar verwaltet.
-
Die URLs der Seiten werden nach Regeln interpretiert, die den Inhalt und
die Navigation widerspiegeln.
-
Dir URLs sollen möglichst keine CGI-Parameter enthalten.
-
Für die Standardanwendungen sollen Datenstrukturen vorgegeben sein,
die um individuelle Attribute erweitert werden können.
-
Zum Erstellen von individuellen Erweiterungen soll eine Skriptsprache zur
Verfügung stehen, mit der spezielle Objekttypen/Datenstrukturen definiert
und verarbeitet werden können. Die selbe Skriptsprache soll für
dynamische (algorithmische) Objekte benutzt werden können.
Eingesetzte Technik:
-
Apache Webserver
-
Perl und eperl als Programmier- und Skriptsprache
-
Apache mod_perl für PerlTransHandler und PerlContentHandler
-
offene indizierbare objektorientierte Datenbank "ObjectDB" basierend auf
GnuDB und Perl (Weitblick Eigenentwicklung)
-
Apache module mod_auth_isp zur Authentifizierung (aus open SourceQuellen
und Weitblick Entwicklung)
Beschreibung der Technik:
Ablauf eines Requests im Apache mit <wdss>
Konfiguration: Der zum <wdss> gehörende PerlTransHandler wird in
einer virtual-Server-Deklaration der Site in den Apache Konfigurationsdateien
eingefügt und die Contentdatenbank der Site installiert.
Requestablauf: Der Apache entscheidet anhand der IP-Adresse und der
"host"-Information aus dem HTTP-Header, daß der entsprechende virtual-Server
den Request
bearbeiten soll. Daraufhin wird der <wdss>-PerlTransHandler aufgerufen.
Der PerlTransHandler analysiert die URL des Requests. Wenn er entscheidet,
daß das <wdss> das Resultierende Dokument für den Request
generieren soll, dann installiert er für diesen Request einen entsprechenden
PerlHandler. Dieser PerlHandler liest aus der
Contentdatenbank der Site das durch die URL angegebenen TemplateObjekt
welches dann die angeforderte Seite im entsprechenden Layout generiert.
Das TemplateObjekt und alle in der weiteren Folge aufgerufenen Objekte
aus der Contendatenbank können auf ein RequestObjekt zugreifen, das
alle Informationen zum aktuellen Request bereitstellt, auf eventuelle CGI-Parameter
zugreifen kann und individuelle customizable Informationen, und gegebenenfalls
Sessioninformationen zur verfügung stellt.
Objekte der ContentDatenbank
In der Contentdatenbank einer Site liegen alle Objekte, die den Inhalt
und Lauout der Site bestimmen. Weitere Objekte steuern das AdministrationsModul
des <wdss> und bestimmen dadurch die Masken und Möglichkeiten sowie
die Zugriffsrechte für die Redakteure. Alle Objekte besitzen einen
eindeutigen Schlüsselnamen über den auf sie im Administrationsmodul
zugegriffen wird. Eine weitere Zugriffsmethode ist die über sogenannte
Filter, welche aus einer Datenbank alle Objekte mit bestimmten eingenschaften
herausholt und in einer Ergebnismenge zusammenstellt. Diese Filter werden
im <wdss> oft angewandt und können inidzierte Zugriffe auf die Datenbank
verwenden. Bein geeigneter Konzeption der Site und Einrichtung von Inizes
ist die Verwendung von Filtern hinreichend Performant und erlaubt größere
Datenmengen
z.B. mehrere 10.000 Addressen oder News zu verwalten.
Die Objekte in einer ObjectDB Datenbank können verschachtelte
Datenstrukturen wie Arrays und Hashes (Namen/Werte Paare) enthalten. Dadurch
können Datenstrukturen wie sie in Perl aufgebaut werden können
auch persistent in der Datenbank abgelegt werden.
Die bei relationalen Datenbanken nötige Definition der Datenstrukturen
und das Anlegen verschiedener Tabellen, sowie einschränkungen der
Feldgröße entfallen bei der ObjectDB. Somit sind beliebig große
Felder in der ObjectDB möglich ohne auf deren Indizierbarkeit verzichten
zu müssen. Der praktische Vorteil liegt dabei vor allem darin, daß
entsprechende Planungsschritte und Datenbankänderungen entfallen.
Perl als Programmiersprache und Skriptsprache für dynamische Seiten
Das <wdss> muß in einer Programmiersprache realisiert werden und
ferner eine Skriptsparsche anbieten, mit deren Hilfe dynamische Seiten
realisiert werden können.
Folgende Eigenschaften von Perl erwiesen sich als Vorteilhaft:
-
schnell, da der Code vor der Ausführung einmalig in einen performaten
Zwischencode übersetzt wird.
-
gestattet einfache Spracherweiterungen in Perl und C
-
unterstützt die Objektorientierte Programmierung
-
ist im Apache durch mod_perl zuverlässig integriert
-
es existieren viele zuverlässige Erweiterungsmoduln z.B. unter www.cpan.org
-
ist sehr gut dokumentiert
-
unterstützt Kompilation zur Laufzeit
-
unterstützt Funktionen höherer Ordnung (Funktionen die Funktionen
generieren)
Nachteile bzw. Einschränkungen von Perl:
-
keine Möglichkeit zur Vorkompilierung
-
keine Laufzeitabfragen der Prototypen von Funktionen
-
nicht vollständige Prototype-Überprüfungen während
des Kompilierens
Besonders hat sich von Vorteil erwiesen, für die Programmierung und
Skriptsprache dieselbe Programmiersprache zu verwenden. Es ist somit einfach
möglich, wiederkehrende Funktionen aus Scripten in ein PerlModul auszulagern
und somit nur noch beim Serverstart kompilieren zu müssen.
Interpretation der URLs
Die Interpretation der URLs im <wdss> sind der herkömmlichen (verzeichnispfadbeschreibenden)
angelehnt. Im <wdss> wird jedoch nicht der Verzeichnispfad, sondern der Navigationspfad (wie kam der Besucher zu dieser Seite), die anzuzeigende
Seite selbst, sowie das Template, welches das Ausgabelayout definiert, in
der URL angegeben.
In der URL http://ihr.name.de/kontakt/kontakt.tel/telefon/index.html
bedeutet:
-
kontakt/kontakt.tel/telefon
-
der Navigationspfad. Die Seite sollte durch nacheinander Anklicken der
Seiten "page.kontakt", "page.kontakt.tel", "page.telefon"
erreichbar sein.
-
telefon
-
die Seitenangabe. Die Seite "page.telefon" wird angezeigt. Genauer
das Objekt "page.telefon" wird aus der Datenbank geholt und nach seiner
HTML-Darstellung gefragt. Diese Darstellung wird vom Template ausgegeben.
-
index.html
-
die Templateangabe. Das Template "template.index.html" wird zur Ausgabe
der Seite benutzt.
Die URL http://ihr.name.de/kontakt/kontakt.tel/telefon/druck.html
würde dieselbe Seite evtl. als Druckausgaben zurückgeben, d.h.
mit denselben Inhalten aber z.B. ohne oder mit anderen Kopf und Fußzeilen
und evtl ohne NavigationsLinks an einer der Seiten.
|
|
Tipp: |
 |
MiniHomepage
Mit dem MiniHomepage-Paket können Sie bei uns auch eine kleine, einfach zu erstellenden und besonders kostengünstige Webpräsenz bekommen.
|
| |
|
|
|
 |
|
© 2005 by Weitblick <wdss>-Service, Eduard Gode •
last update: Wed May 31 10:03:33 2023 by
Webmaster •
Druckversion
|
< zurück |
nach oben scrollen^
|
