Zunächst sei gesagt, dass wir von einer 2. Auflage noch weit entfernt sind und es zum jetzigen Zeitpunkt nicht sicher ist, ob und wann es sie geben wird. Trotzdem sollten wir frühzeitig anfangen, Ideen dafür zu sammeln, damit nachher auch das drin steht, was die Mehrzahl der Nutzer lesen will. Schließlich schreibe ich das Buch ja nicht für mich

Es wurde immer wieder der Wunsch nach mehr Entwickler-Infos bzw. einem Entwickler-Handbuch geäußert, obwohl ich der Meinung war, dass alles wichtige zur Entwicklung mit TYPOlight gesagt war. Da ich ganz offensichtlich falsch lag, möchte ich in diesem Thread gerne konkret wissen, welche Entwickler-Themen ihr gerne in der nächsten Auflage behandelt hättet.

Bitte beschreibt eure Wünsche detailiert, so dass ich (und andere Leser) mir etwas darunter vorstellen kann.

Gute Beschreibung: Ich wünsche mir in der nächsten Auflage ein ausführliches Beispiel, wie man bestehende Templates (z.B. von Open Source Webdesign) in TYPOlight importiert und daraus ein Seitenlayout erstellt.

Beschreibung mit viel Potential: Mehr Infos zur Modulentwicklung.

Hallo leo,

als erstes ein großes Lob von mir, das Buch ist super und sehr verständlich geschrieben! (Zumindest bis zum Punkt "Die Seitenstruktur", weiter bin ich noch nicht. )

Ich habe zwar kein Wunsch/Vorschlag zum Thema Entwicklung. Mir geht es eher um Formulierungen auf den Seiten 59/60:

Seite 59

Zitat:

SPEICHERN UND SCHLIESSEN: Beim Klick auf diese Schaltfläche werden ihre Eingaben gespeichert, und gelangen zurück zur vorherigen Seite.

1. "[...] gespeichert, und gelangen zurück zur vorherigen Seite."
Vorschlag: "[...] gespeichert(,) und Sie gelangen zurück zur vorherigen Seite."

Seite 60

Zitat:

SPEICHERN UND ZURÜCK: Beim Klick auf diese Schaltfläche werden Ihre Eingaben gespeichert, und Sie werden auf die übergeordnete Seite weitergeeitet. Diese Schaltfläche steht Ihnen im Parent View zur Verfügung und bringt Sie nach der Bearbeitung eines Kindelements zurück zur Übersicht der Elternelemente.

1. "[...] Eingaben gespeichert, und Sie [...]"
Vorschlag: "[...] Eingaben gespeichert(,) und Sie [...]"

Nun noch eine Verständnisfrage zu diesen beiden Abschnitten. Als ich diese gelesen habe, musste ich erst eine Weile überlegen, was nun der Unterschied zwischen "SPEICHERN UND SCHLIESSEN" und "SPEICHERN UND ZURÜCK" ist. Erst durch Ausprobieren im Backend habe ich verstanden, was gemeint ist. Allerdings verstehe ich hier nicht den Sinn beider Funktionen, bzw. der Formulierungen. Müssten die Wörter "schließen" und "zurück" nicht vertauscht werden?

SPEICHERN UND SCHLIESSEN: Hier gelangt man auf die vorherige Seite zurück.
SPEICHERN UND ZURÜCK: Hier schließt man die Oberfläche und man gelangt zur Parent View.

Das klingt unlogisch. Verständlicher wäre es so:

SPEICHERN UND SCHLIESSEN: Hier schließt man die Oberfläche und man gelangt zur Parent View.
SPEICHERN UND ZURÜCK: Hier gelangt man auf die vorherige Seite zurück.

...Davon abgesehen, dass diese Formulierungen "schließen" und "zurück" meiner Meinung nach sowieso etwas verwirrend sind. Denn was ist der Unterschied zwischen "Parent View" und "vorherige Seite" ? Die vorherige Seite ist doch eigentlich immer die Parent View. Und bei der Funktion von "SPEICHERN UND ZURÜCK" wird eine Ebene übersprungen.

Beispiel, wie es gerade ist:
Ebene1: Artikel-Liste
Ebene2: Artikelelement-Liste eines Artikels
Ebene3: einzelnes Artikelelement

Ebene3 -> SPEICHERN UND ZURÜCK -> Ebene1 | Hier wird eine Ebene übersprungen. Man gelangt also zur Grand-Parent-View.
Ebene3 -> SPEICHERN UND SCHLIESSEN -> Ebene2 | Hier gelangt man zur eigentlichen Parent View (Artikelelement-Liste).

Beispiel, mein Vorschlag:
Ebene3 -> SPEICHERN, ZURÜCK -> Ebene2 | Hier gelangt man zur Parent View (Artikelelement-Liste).
Ebene3 -> SPEICHERN, ÜBERSICHT -> Ebene1 | Hier gelangt man zur Artikel-Liste.


Gruß,
Shade

Ich sehe Bedarf an einer ausführlicheren Beschreibung zum Thema Haupt-Template. Viele Leute sind es gewohnt ein eigenes Template für ein WebCMS erstellen zu müssen und machen dies (speziell nach Bens Tutorial) auch bei TYPOlight. Dies ist aber überhaupt nicht notwendig, da man sehr viel mit Boardmitteln und etwas CSS abdecken kann. Ich persönlich habe bislang keine einzige TL-Seite online, bei der ich ein eigenes Template erstellen hätte müssen (mal abgesehen von kleinen Änderungen in nav_... etc).

Psi:

Viele Leute sind es gewohnt ein eigenes Template für ein WebCMS erstellen zu müssen und machen dies auch bei TYPOlight

Das würde zumindest erklären, warum so viele Installationen ohne Copyright-Hinweis auftauchen

Klar, war auch einer meiner ersten Schritte mit TYPOlight aber nach näherer Betrachtung deines Templates und dem YAML-Framework war das dann Geschichte.

Eventuell wäre hier ein Screencast sehr hilfreich.

Die Themen "eigenes Seitenlayout/Template" und "wie nutze ich das CSS-Framework" werde ich also auf jeden Fall in der 2. Auflage ausführlich behandeln.

Kleine Anmerkung zur aktuellen Ausgabe S.140:

"Navigation Unterpunkte" wird als obsolet dargestellt. Wenn man aber ein HauptNav-Modul Level1 Hard Limit, Subnav Level2 Hard Limit und eine davon abhängige 3. Navigation erstellen möchte, geht das nur mit "Unterpunkte". Zumindest wenn dieses "aufklappen" soll.

Ich finde auch, dass der Entwickler-Bereich nicht weit genug geht, die Themen sind ja meistens nur angerissen. Ganz spezielle Wünsche wären vor allem nicht offensichtliche Zusammenhänge, also wie zum Beispiel die config-Einstellungen ptable und ctable sich auf die Felder, Feldinhalte und Logik auswirken. Das sieht man zwar in Action bei page, article und content - aber ohne Erklärung ist das schwer nachzuvollziehen. Als wahrscheinlich mächtiges Feature wäre hier ein Punkt wo man noch deutlich Potential aus dem Framework Typolight ziehen kann.

Gruß
Markus

Mir persönlich wäre schwer daran gelegen, dass aufzuteilen in ein Entwickler Handbuch (oder Admin Handbuch) und eines rein für "Arbeiter" in TL. Mir stellt sich jetzt schon zum wiederholten Male das Problem, was ich einem Kunden an die Hand gebe, damit er sich mit dem System auseinander setzen kann. Es gibt zwar das ausgezeichnete Handbuch für Redakteure aber es ist für mich keine wirkliche tragbare Lösung, das jedesmal im CopyShop drucken zu lassen und weiter zu geben. Ich finde, ein Kunde muss nichts über die Administration eines CMS wissen, da verstellt man schnell mal was... Wenn er trotzdem wollen würde, kann er sich dann ja das Admin Handbuch kaufen....

Geht zwar etwas weit, aber vielleicht könnte man da eine Aufgabenteilung herbeiführen, das z.B. Nina Gerling hier in Absprche mit Dir selbst ein Buch veröffentlicht, und Du dann mehr den technischen Part übernimmst?

Grundsätzlich würde ich mir im Buch mehr Infos zu geschlossenen Benutzerbereichen wünschen. Ich gehe davon aus, dass das für viele mittlerweilen ein wichtiger Bereich ist, der aber in einer Art Überblick erklärt werden sollte. So eine Art Kapitel "Wie realisiere ich eine Webseite mit geschlossenem Bereich".

Was ich noch ändern würde ist die ganze Sache mit den lokalen Installationen. Ich finde, das gehört nicht zu TL, da sollen sich die Leute ein eigenes Buch für XAMPP kaufen.

Ich kann mich da meinem Vorredner nur anschließen.
Meiner Meinung nach wäre ein Entwickler Handbuch sehr gut.
Am Besten mit recht vielen Beispielen, wie man Extensions entwickelt. Man kann das ganze Buch ja an einer Ext aufhängen, die man von Anfang an mit dem Leser schreibt. Angefangen mit den Tabellen Definitionen über das Backend bis hin zum Frontend. Auch Hooks und alles, was dazu gehört.

Ich würde mir soetwas wünschen, da ich jetzt zwar auf dem Gebiet PHP und Informatik allgemein nicht schlecht aufgestellt bin, aber mit fehlen bei den Entwickler-Dokumenten einfach Beispiele und eine Guideline. Da finde ich die Doku zu dünn.

Folgende Punkte zum Thema Entwicklung fände ich interessant:

- Wie man komplexere Module (Events, News) die aus verschiedenen Modulen und parent und child Elementen bestehen aufbaut.
- Wie und wo callbacks optimal genutzt werden können.
- Wie man bestehende Module wie z.B Kommentare in eigene Module integrieren kann.
- Welche Möglichkeiten man bei der Entwicklung von Modulen hat (Aufbau mit oder ohne DCA).
- Wie man Hilfsmodule die ins System eingreifen erstellt.
- Vielleicht noch ein Schema wie der Gesamtprozess aufgebaut ist. (Siehe thyons Grafiken)
- Einen Beispiel Workflow der weniger die einzelnen Schritte sondern eher die Vorgehensweise erklärt.

Das wichtigste aus meiner Sicht ist einem Entwickler der neu zu TYPOlight kommt
mit dem Buch vermitteln zu können was grob mit dem System machbar ist.

Ich habe das Buch auch gekauft und mittlerweile fast ganz gelesen. Viele Fragen haben sich damit geklärt .

Die Unterscheidung für Entwickler und Anwender/Administratoren fände ich auch gut. Der Wissenstand der Zielgruppen ist eben sehr unterschiedlich.

Was mir noch immer unklar ist und dort mit erläutert werden sollte (hier erwarte ich darauf nun keine Antwort!):

1. Welchen Unterschied mach es, ob ich ein Inhaltselement wie z.B. "Tabelle" nutze oder die Tabelle mit dem TinyMCE erstelle und zwar in Bezug auf Erweiterbarekeit, Formatierung und Suchmaschinenfreundlichkeit. Sprich, für welchen Anwendungszweck ist was besser?

2. Zum Thema .pdf's erzeugen und diese formatieren habe ich so gut wie nichts gefunden. Eine Druckfunktion finde ich wichtig. Daher fände ich es gut, wenn erklärt würde, was die unterschiedlichen pdf Erzeugungsmodule können, wo ihre Grenzen sind und wie man sie einsetzt (formatiert). Oder auch detailiertere Hinweise dazu, wo man sich dazu einlesen kann.

Eine XAMPP Installation habe ich zwar nicht und somit auch die Erläuterungen nicht genutzt, finde es aber grundsätzlich gut das es mit aufgenommen wurde, da man auch Einsteiger ansprechen will. Das erleichtert dann schon vieles.

Wozu Fragen stellen wenn man keine Antwort erwartet?

Shania:

1. Welchen Unterschied mach es, ob ich ein Inhaltselement wie z.B. "Tabelle" nutze oder die Tabelle mit dem TinyMCE erstelle und zwar in Bezug auf Erweiterbarekeit, Formatierung und Suchmaschinenfreundlichkeit. Sprich, für welchen Anwendungszweck ist was besser?

Das Content-Element Tabelle erzeugt bei der Ausgabe deutlich mehr CSS-Klassen, jede Zeile, Spalte und Zelle ist einzeln ansprechbar. Die Formatierung wird dadurch um Welten einfacher.

Shania:

2. Zum Thema .pdf's erzeugen und diese formatieren habe ich so gut wie nichts gefunden. Eine Druckfunktion finde ich wichtig. Daher fände ich es gut, wenn erklärt würde, was die unterschiedlichen pdf Erzeugungsmodule können, wo ihre Grenzen sind und wie man sie einsetzt (formatiert). Oder auch detailiertere Hinweise dazu, wo man sich dazu einlesen kann.

Die Unterschiede sind im Backend von Typolight unter Einstellungen minimal erklärt, die Anwendung ist leider nicht ganz so einfach, weil eben manches funktioniert wie erwartet, manches aber auch nicht (als Folge der verwendeten PDF-Bibliotheken). TCPDF kann Unicode, ist fix und erstellt schön kleine Dateien, kann aber mit CSS nichts anfangen. Es werden nur die Grundlegenden HTML-Tags ausgewertet, für ein Layout der Ausgabe müssten HTML-Tabellen verwendet werden. DOMPDF kann CSS auswerten, ist dafür langsamer und hat keine Unicode-Unterstützung. Es werden auch nicht alle CSS-Angaben fehlerfrei übernommen, das Ergebnis liegt aber meist nah an dem was man erwarten würde.

Gruß
Markus

Aus momenanter Sicht wünsche ich mir ebenfalls alle Punkte, die Schlauchbeutelmaschine bereits erwähnt hat. Das sind genau die richtigen Themen, die einen interessieren, wenn man in die Entwicklung mit TL einsteigen möchte.

Ich poste das nur noch einmal, damit ich diese Aussage hiermit noch einmal unterstreiche.

Ich kenne leider die 1. Auflage nicht, aber was ich bisher generell noch nicht gelesen habe ist :
- Was unterscheidet TL grundlegend zu anderen CMS ? Sind Injections moeglich, was wird dagegen gemacht, wie wird dies verhindert ?
- Wie muesste TL aussehen, um ein Enterprise System sein ?
- Wie sieht die Zukunft von TL aus, in welche Richtung geht es.


Also eher allgemein gehaltene Wuensche, die man als Argumentationshilfen bei potentiellen Kunden anfuehren kann.

Wenn dies bereits in der ersten Auflage erwaehnt oder darauf eingegangen wurde, bitte ich dies zu entschuldigen.