Mammut-System?
Wer hier an die Steinzeit denkt liegt falsch. Es handelt sich hierbei vielmehr um ein modulares, objektorientiertes PHP-5 System für den gehobenen Anspruch.
Wieso Mammut? Weil dahinter ein großes, mächtiges und robustes System steht - jedoch nicht auf Basis von Steinzeittechnik!
Framework und CMS?
Da manche Teile der Entwicklung, wie beispielsweise die Datenbankabstraktion auch für andere Projekte interessant sind, wurde das System in diese beiden Bereiche aufgeteilt.
Das Framework enthält alle Klassen und Funktionen, die eigenständig verwendbar sind und somit auch in anderen Entwicklungen verwendet werden können, ohne speziell auf die für ein CMS typischen Konventionen zu achten.
Das CMS basiert auf dem Framework, baut dieses jedoch zu einem kompletten Webseitensystem aus.
Warum noch ein weiteres Framework/CMS?
Die meisten existierenden Systeme sind darauf ausgelegt, möglichst einfach eingerichtet zu werden, um möglichst schnell einfachere Webseiten zu erstellen. Dies geht jedoch meist zulasten der Flexibilität, wenn komplexere Lösungen zu realisieren sind.
Hier setzt nun die Stärke des Mammuts ein. Statt selbst die Systembedingungen vorzugeben, wird hier versucht, eine möglichst flexible Grundlage bereitzustellen, um den Webauftritt oder die Webanwendung möglichst gut im Bezug auf die angebundenen Systeme umzusetzten.
Dies äußert sich beispielsweise in folgenden Punkten:
- Multiseiten-Unterstützung
Erstellen und Verwalten von mehrern Seiten auf einer Installation, definiert durch (Sub-)Domains. - Flexible Wahl der primären Datenbank (und andere Systeme)
Die meisten populären SQL-Datenbanken werden als Datenbank unterstützt (z.B. MySQL, MariaDB, PostgreSQL, SQLServer). Auch können in einer Installation Daten von unterschiedlichen Datenbanken gleichzeitig verwendet werden - dank der Datenbankabstraktion auch mit einer funktionalen Schicht bei entsprechender Programmierung OHNE Codemodifikationen!
Hierdurch wird auch ein späterer Wechsel des primären Datenbanksystems, etwa von MSSQL zu MySQL, möglich.
Ähnliches gilt auch für Webserver oder (PHP-)Caches... - Unterstützung von alternativen Benutzerdatenquellen
Besonders bei Webanwendungen im Unternehmensumfeld sind meist schon etablierte Verzeichnisdienste zur Benutzer- und Gruppenverwaltung vorhanden (Active Directory, eDirectory, LDAP). Diese können bereits im Standard als Basis für die Autorisierung der Benutzer und die Verwaltung der Gruppen verwendet werden. - ALLES ist austauschbar
Praktisch jeder Aspekt im System ist so angelegt, das er je nach Bedarf entweder in einer OOP-typischen Weise verändert, erweitert oder ausgetauscht werden kann. Ein Beispiel hierfür wäre das Handling von Layout-Templates, bei dem das Standard-PlugIn auch durch ein PlugIn ausgetausch werden kann, das Templates des Joomla-CMS verwenden kann.
Im Gegensatz zu anderen System endet beim Mammut dies nicht bei genau definierten PlugIns, sondern zieht sich konsequent bis zur grundsätzlichen Anfrageverarbeitung hindurch. - Business-Anforderungen bedacht
Anforderungen wie Datenkonsistenz durch Transaktionen oder Hochverfügbarkeit/Lastverteilung durch Clusterinstallationen sind bei der Entwicklung bedacht worden. So ist es möglich, Anfragen auf mehrere Server und Datenbankknoten zu verteilen, ohne das hierbei Probleme durch inkonsistente Caches oder Sessions entstehen. Auch gibt es Möglichkeiten für automatisierte zeitgesteuerte Prozesse. - Trennung von Modellierung, Code und Design
Da es meist zu Problemen kommt, wenn Designer, Programmierer und andere Personen an den selben Dateien arbeiten gibt es in Mammut die Möglichkeit, diese Bereiche weitestgehend zu trennen. So ist es möglich, das ein Koordinator Datenobjekte in einer DSL zu definieren, ein Entwickler generiert hierraus Code und entwickelt die Business-Logik und ein Designer entwickelt in separaten und von Logik freien Templates die Benutzeroberfläche. - Codegenerierung
Durch eine auf Eclipse/xText basierende Modellierungsspache und den dazugehörigen Editoren (mit den typischen Funktionen wie Syntaxcheck oder Autovervollständigung) ist es möglich, viele grundlegende Dateien konsistent und standardisiert zu erzeugen. Beispielsweise können hiermit Datenmodelle definiert werden, aus denen die entsprechenden Klassendateien für Modelle, Standardfunktionen in einem dazu passenden Service und die nötigen Tabellendefinitionen in einer datenbankneutralen XML-Datei erstellt werden. Sogar Skripte zum Update von Versionen können auf diese Art generiert werden.
![]() Admin-Interface |
![]() Standardseite bearbeiten |
![]() Mehrere Datenbankverbindungen |
![]() Modellierung in Eclipse |
Typische Einsatzszenarien sind Internet und Intranetportale, welche spezielle Funktionen enthalten sollen wie die Anbindung von Drittanwendungen (ERP/CRM) oder nach Kundenvorgaben erstellte Datenverarbeitungsprozesse.