Checklisten für Framework-Entwickler #

Diese Seite richtet sich an Entwickler, die lieber Punkte abhaken als Kapitel lesen. Jeder Punkt verweist auf die Seite, die ihn erklärt.

Inhalt #

1. Exponential für ein Projekt bewerten
2. Eine Entwicklungsumgebung einrichten
3. Ein erstes Modul prüfen
4. Eine Anwendung live schalten

Exponential für ein Projekt bewerten #

• To do: Die Daten, die Redakteure verwalten, sind aufgelistet, und jede Art ist entweder eine Inhaltsklasse oder eine eigene Tabelle (Das Inhaltsmodell).
• To do: Websites, Sprachen und Zielgruppen sind Siteaccesses zugeordnet (Siteaccesses).
• To do: Berechtigungen sind als Rollen mit Funktionen und Einschränkungen beschrieben (Autorisierung).
• To do: Jede Funktion, auf die Sie zählen, ist im Produkt und in der Distribution geprüft, die Sie installieren werden, und nicht aus einem anderen Framework abgeleitet (Die Plattformprodukte, Begriffswörterbuch: keine direkte Entsprechung).
• To do: Das Team hat Wann Sie Exponential wählen sollten gelesen.

Eine Entwicklungsumgebung einrichten #

• To do: Eine lokale Installation: ./console exp:install --apply (SQLite) (Installation mit einem Befehl).
• To do: config.env.php mit EXP_ENV=dev; Debug-Ausgabe und der Mail-Transport file in der Variante dev (Umgebungen und Geheimnisse).
• To do: Velocity mit Engine=qbix oder Apache bzw. nginx mit PHP-FPM (Server und Deployment).
• To do: Template-Pfad-Kommentare und die Debug-Leiste eingeschaltet (Debugging).
• To do: Eine eigene Erweiterung, aktiv, in einem eigenen Git-Repository (Pakete, Entwicklungsumgebung).

Ein erstes Modul prüfen #

• To do: Jeder View nennt seine Richtlinienfunktionen in module.php (Routing).
• To do: Parameter werden umgewandelt und geprüft; Weiterleitungsziele werden geprüft (Validierung).
• To do: Jeder ausgegebene Wert wird mit wash behandelt (Die View-Schicht).
• To do: Formulare senden das Formular-Token mit; $_POST wird nirgends direkt gelesen (Formulare und CSRF).
• To do: Kein SQL in Inhaltstabellen; persistente Objekte oder maskiertes SQL für eigene Tabellen (Abfragen).
• To do: Kein Zustand pro Request in statischen Eigenschaften (Server und Deployment).
• To do: Einstellungen sind in der INI-Datei Ihrer Erweiterung dokumentiert, Geheimnisse liegen nur in settings/override/ (Konfiguration).
• To do: Logik in Klassen mit Unit-Tests, die ohne Datenbank laufen (Testen).
• To do: Kein Inline-<style> und kein style="" in Administrations-Templates (Styling von admin4).

Eine Anwendung live schalten #

• To do: Ihr Schema und Ihre Klassen lassen sich mit einem Befehl installieren; für spätere Releases gibt es Upgrade-Schritte (Migrationen).
• To do: Die Cronjob-Teile frequent und infrequent, Ihre eigenen Teile und die Queue-Worker sind eingeplant (Geplante Aufgaben, Warteschlangen).
• To do: Die Debug-Ausgabe ist für Besucher ausgeschaltet; Geheimnisse sind pro Maschine mit dem Modus 0640 gesetzt.
• To do: [HTMLForms] Secret ist für die Installation gesetzt (Formulare und CSRF).
• To do: Caches und HTTP-Header sind festgelegt: View-Cache, Cache-Blöcke, HTTP-Cache, Velocity-Response-Cache (Caching, HTTP-Caching).
• To do: Der Ablauf eines Releases ist aufgeschrieben und auf Staging erprobt (Server und Deployment).
• To do: Die Anleitung zur Sicherheitshärtung wurde gelesen (Sicherheitshärtung).
• To do: Die Checkliste für den Website-Start ist für die öffentliche Website abgearbeitet (Checkliste für den Start).

Verwandte Seiten #

• Zehn Stolperfallen für Framework-Entwickler
• FAQ für Web-Framework-Entwickler
• Sicherheit für Anwendungen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.