Futuretable: Unterschied zwischen den Versionen
Aus Contao Community Documentation
Toflar (Diskussion | Beiträge) (→Technisch) |
|||
Zeile 24: | Zeile 24: | ||
* Objective-Relational-Mapping (ORM) - Mögliche Frameworks: Doctrine ORM | * 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)] | * 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)] | + | * 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 | * Virtual File System, VFS | ||
* Access Control List (ACL) (via Permissions) + Role Based (+ multiple Identities, also Trennung von Anmelde- und Benutzerinformationen) | * 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) | * Globale Validatoren (damit Widgets, die identisch validieren, den gleichen Validator nutzen) | ||
− | * Ü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)] | + | * 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 | * Versionierung von Inhalten nicht über separate Tabelle, sondern in die Inhaltstabellen integriert | ||
* Verbesserte relationale Baumstrukturen | * Verbesserte relationale Baumstrukturen |
Version vom 5. September 2011, 15:58 Uhr
Inhaltsverzeichnis
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
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).
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)