Aktuelle Version vom 19. November 2011, 23:10 Uhr

In diesem Dokument sollen die Wünsche und Pläne für Contao3 geordnet und zusammengefasst aufgelistet werden.

Wir haben und wollen behalten

• Übersichtliches einfaches Backend
• Strukturierte Inhalte
• Frontend Themes aus Modulen, Layouts usw.

Wir haben und können eventuell drauf verzichten (zu Gunsten von etwas besserem)

• Einfaches Caching
• Einfache Request Klasse
• Session Handling für Logins etc.
• Browser Detection
• Class Loader
• File-Handling
• Übersetzungen für statischen Text
• Validatoren pro Widget

Ein Muss für die Zukunft

Technisch

• PHP 5.3 Namespaces
• Database Abstraction Layer (DBAL) - Mögliche Frameworks: Doctrine DBAL
• Objective-Relational-Mapping (ORM) - Mögliche Frameworks: Doctrine ORM
• Umfangreiches Caching [Was ist hiermit gemeint? Was den FECache angeht, wäre es super, wenn wir das über die htaccess ziehen könnten, ähnlich wie das bei WP das Supercache Modul mach (backbone)]
• HTTP Request Handler [Was ist hiermit gemeint? (backbone) Klassen die mit HTTP-Requests umgehen (Toflar); Immer noch net genau genug? Klassen die mit dem derzeitigen Request umgehen? Da hat Symfony die Request/Response Klassen die man auch separat ohne das ganze FW nutzen könnte. Oder klassen die einen HTTP-Request ausführen können? (backbone);]
• Virtual File System, VFS
• Access Control List (ACL) (via Permissions) + Role Based (+ multiple Identities, also Trennung von Anmelde- und Benutzerinformationen)
• Globale Validatoren (damit Widgets, die identisch validieren, den gleichen Validator nutzen)
• Inhalts-Übersetzungen auch auf DB-Ebene [Würde das nicht auf DB-Ebene zwingen, lieber einen Übersetzungsdatei-Editor (backbone) Das meinte ich nicht, ich meine Datensätze für verschiedene Sprachen editierbar zu machen. Sowas gehört garantiert nicht in ein File ;-) (Toflar); hab mal das konkretisiert in im Stichpunkt (backbone)]
• Versionierung von Inhalten nicht über separate Tabelle, sondern in die Inhaltstabellen integriert
• Verbesserte relationale Baumstrukturen
• UUIDs anstelle von numerischen IDs (Erlaubt Dateninteroperabilität zwischen verschiedenen Installationen).

Funktional

• Template Engine (Twig, Smarty)
• Ein neues, richtig geiles Extension Repository
• Gut Dokumentiert
• Einfach zu handhaben
• Auslagern von Standardkomponenten (Nachrichten, Events, Newsletter usw.) in Erweiterungen (die eventuell bei einer Standardinstallation mitgeliefert werden).
• Besseren Formulargenerator
  • Subpaletten, wie gehabt
  • bessere Widgets mit mehr Javascript
  • Widgets alla MultiTextWizard zur Pflege von Kinddatensätzen, hier ggf. auch Subformulare (dcawizard)
  • Formulare über mehrere Seiten
  • abgekoppelt vom Speicherort

Nice to have

• Updatefähig (Contao 2 -> Contao 3) [auch ein Muss, aber wenn die Erweiterungen nicht kompatibel sind, stelle ich mir das schwer vor (Glen) Naja, der Core muss sich ja updaten können und ich denke da geht es vor allem um Content, nicht um Settings oder Dinge von Erweiterungen (Toflar)]
• Ein neues Backend-Theme, mehr Javascript/Ajax für den User wie z.B. Drag n' Drop etc. Dinge die uns HTML5 bringt - Dinge die nicht dazu erfunden wurden, um links liegen gelassen zu werden! [würde ich als Muss, bezeichnen (backbone)]
• WebDAV Access auf die Dateiverwaltung
• Zuordnung von Inhalten/Seiten zu Publication-Sets, welche von einer Publication verwendet werden um für einen bestimmten Zeitraum den Zustand der Seite zu representieren. Also sozusagen, ein integriertes Dev -> Stage -> Live System.
• Jeder Inhalt, der eine eigene Seite erfordert (Newseinträge), bekommt auch einen Eintrag in der Seitenstruktur, damit die Seitenstruktur die komplette URL-Struktur representiert.
• INSERT-only Prinzip für Inhalts-/Seiten-Tabellen (und DELETE von alten/ungenutzen Datensätzen)
• Dualer Datenbank Zugriff, Möglichkeit für 2 verschiedene Datenbankaccounts: Einer der alles außer GRANT darf und einer der nur DML darf. Somit kann sichergestellt werden das DDL nur nach expliziter Erlaubnis des Users möglich ist. (Der Code der DDL ausführen möchte, muss eine Art "Systemcall" durchführen, der checkt, ob der BE-Benutzer überhaupt die Permission für DDL hat, wenn ja wird der Nutzer explizit gefragt. Bei Bestätigung wird die DDL-Query ausgeführt und anschließend mit einem Callback im "Usercode" weitergemacht)