Hello,
Die Betonung liegt hier auf "Möglichkeit". Ein Anfänger sollte idealerweise keine Einstiegsprobleme haben, aber er sollte auch nicht ausgebremst oder zum Systemwechsel gezwungen werden, wenn er fortgeschritten ist.
Das verstehe ich jetzt nicht. Was haben die Fähigkeiten eines Anfängers mit den Fähigkeiten eines Template-Systmes zu tun?Wie auch immer man Template-System definieren mag - für mich ist das nicht wichtig. Ein System sollte der Erfüllung seiner Aufgabe dienen und nicht einem theoretischen idealistischen Gebilde. Als Nebenforderungen sollte es einfach zu verstehen sein und auch bei zukünftigen Wünschen noch verwendbar sein. Ein System sollte für einen Anfänger keine zu hohe Hürde darstellen und gleichzeitig einen Fortgeschrittenen nicht zu sehr einschränken. Es sollte sich also quasi den Fähigkeiten des Anfängers beugen und mit denen des Fortschreitenden mithalten können.
Ja ok, dagegen habe ich auch nichts einzuwenden.
Trotzdem sollte das System nicht "aus Versehen" mehr können, als es für den sicheren Betrieb können muss. Ein Mailserver sollte Mails versenden können und keine wilden Zugriffe auf das Dateisystem seines Hosts ermöglichen. Eine Datenbank sollte Daten speichern und strukturieren können und nicht Programme möglich machen, die auf dem Host herumvagabundieren können. Gegen Datenbank-interne Programme ist nichts einzuwenden. Ein Template-System sollte die benutzerdefinierbare Darstellung von Daten ermöglichen, aber keinen Zugriff auf weitere Funktionalitäten des Hosts oder des Programmes ermögichen, für das es arbeitet.
Woher die Daten kommen, ist Aufgabe eines anderen Sub-Tools der Anwendung, nämlich z.B. die eines Abfragesystems / Abfragegenerators. Klassische Abfragegeneratoren haben auch immer die Erstellung einfacher "Templates" (das nannte man früher Formulare) ermöglicht; in unserem Fall sind wir aber einen Schritt weiter und sollten das strikt trennen.
Die Vereinfachung im Umgang mit Templates liegt mMn nun darin, sie in überschaubare Einheiten zu zerteilen, die der User nach und nach kaskadieren kann und so zu einem Gesamtkunstwerk zusammenbauen kann. Dieses muss er sich sowohl in Einzelteilen als auch im Gesamten mit "Dummydaten" ansehen können. So kann er dann intuitiv auch Bauvorschriften für komplexere Views erzeugen.
Welche Elemente benötigt werden und welche davon zugelassen werden, ist vom Anwendungsfall abhängig.
Welche Elemente muss ein Templatesystem denn können?
ich fang mal an, vielleicht machen die Mitleser ja einfach mal mit.
- statische Darstellungen ohne Daten
- statische Darstellungen mit Daten
- dynamische Listen (je mehr Daten, desto länger. Ggf. blätterbar)
- Treaddarstellungen
- Menus
- statische Eingabe-Formulare
- dynamische Eingabe-Formulare (je mehr Daten, desto länger. Ggf. mehrseitig)
- link-sensitive Darstellungen (also mit Verzeweigungen zu anderen Templates)
- ???
Wie müsste man z.B. einen Monatskalender abbilden, der ja jeden Monat etwas anders aufgebaut ist / mit einem anderen Wochentag beginnt? Wie müsste ein Template dafür aufgebaut werden?
Wie müsste man vorgehen, wenn er Termine enthalten können soll, die bei Anklicken auch noch im Detail angezeigt werden sollen?
Was soll denn erreicht werden?
------------------------------
Wie baut man die Elemente nun so auf, dass es nachher egal ist, was man damit darstellen will? Im "Baukasten" finden sich immer die passenden Standardelemente (normalisierten Teillösungen), aus denen man das Gewünschte zusammenbauen kann ...
HTML kann auch nicht alles. Es ist eine lose strukturierte Bauteilesammlung. Nicht alle Elemente sind wirklich logisch, weil gewachsen... Das W3 versucht nun nach und nach, einen sinnvollen Plan in diese gewachsene Sammlung zu bringen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg