[TYPO3-german] Fehlendes/Entfallenes Feld section_frame in der 7er LTS

[Dr Dieter Porth]

Am 13.11.2015 um 23:36 schrieb Lars Brinkmann:
> Hallo Philipp,
>
> das ist ja so ein bisschen das, was ich kritisiere. Man schmeißt
> Felder raus, die einfach per TypoScript angesprochen werden
> konnten und muss sie anschließend "mühsam" per Extension
> wieder hinzufügen. Dieser Weg erschließt sich mir noch nicht.
>
> Das mag aber daran liegen, dass diese Version noch sehr
> frisch ist und man sich nun erst einmal zurecht finden muss.
>
> Da es aber in Fällen nur ein Wert ist, den man dann im FSC
> abfragt, mag es vielleicht wirklich die bessere Methode sein.
> Immerhin fällt im Backend ja der komplette Bereich section_frame
> weg und der Bestand ja nicht _nur_ aus einem Datenbankfeld.
>
> Viele Grüße, Lars Brinkmann
>
> Am 13. November 2015 um 16:00 schrieb Philipp Gampe <philipp.gampe at typo3.org>:
>> Hi Lars,
>>
>> Lars Brinkmann wrote:
>>
>>> Und wirkliche Alternativen oder Best Practice-Empfehlungen für die nun
>>> fehlenden  Punkte gibt es ja nun auch nicht.
>> Doch. Wenn du extra Felder brauchst, dann baue eine eigene Extension, welche
>> diese Felder mitbringt.
>> Das geht mit dem Extension Builder ganz leicht (zumindest wenn man weiß wie
>> er Property Namen auf Datenbankfeld Namen mappt.
>>
>> Grüße
>> --
>> Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
>> Certified Integrator – Active contributor TYPO3 CMS
>> TYPO3 .... inspiring people to share!
>>
>> _______________________________________________
>> TYPO3-german mailing list
>> TYPO3-german at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>
>

Wenn ich die Entwicklung richtig lese, wird TypoScript als
Konfigurations- und Templating-Sprache langfristig durch die
Fluidtemplates abgelöst werden.
Es macht also gemäß einer Salami-Taktik durchaus Sinn das
section_frame-Feld raus zunehmen. Vielleicht gibt es dann in einer
kommenden Version 8 ein eigenes Modell zur Steuerung von
Layout-Anweisungen, welches Inhalte und Layout sauber trennt. Es wäre
wirklich cool, wenn man ein solches System-Layout, ähnlich wie die
Categories, einfach in Templates integrieren könnte. Der Vorteil eines
solchen System-Layouts wäre, dass der Redakteur beim Workflow sauber
zwischen Inhaltpflege und Layoutpflege unterscheiden könnte. Für den
Entwickler wäre ein solches System-Layout hilfreich, weil er in
verschiedenen Extensionen immer die gleichen Layout-Vorlagen nutzen könnte.

Das TYPO3-Handbuch ist veraltet. Schade ist, dass es bisher kaum ein
didaktisch gut aufbereitetes Werk gibt, was beschreibt, wie man am
besten das TYPO3-Fluid sinnvoll und übersichtlich einsetzt bzw. wie man
die typischen Standard-Probleme mit Fluidtemplates löst. Da die
Modularisierung auch Einfluss auf die Entwicklung von Webseiten hat,
sollte ein solches neues Handbuch sich auch mit dem Workflow von
Website-Entwicklungen und mit Strategien zur Fehlersuche beschäftigen.
Insbesondere das Prinzip 'convention over configuration'  und die
Aufsetzung von Website über Konfigurationsdateien führt einfach dazu,
dass funktionale Änderungen oft syntaktisch korrekte Änderungen in
verschiedenen Dateien erfordern. Die Art, wie man eine Website aufsetzt,
hat sich definitiv geändert, wenn man statt Typoscript die
Fluidtemplates nutzt.
Wünschenswert wäre natürlich, wenn man zukünftig auch Funktionstest für
die Fluid-Templates schreiben könnte, um die Funktionalität eines
flexiblen  Templatings sicherstellen zu können.

Mehr als das weggefallene Feld ärgert mich am neuen TYPO3 das
persistenter gewordene 'Caching'. Schon mehrmals ist es mir passiert,
dass ich bei der Entwicklung einer Extension meine Fehler erst auf einem
Stagingserver sichtbar wurden. Obwohl ich lokal den typo3temp-Ordner
gelöscht habe und Cachetabellen leerte, trat zum Beispiel ein
Definitionsfehler in der TCA lokal nicht auf.
Auch macht die Dropdown-Liste für das Saven macht die Nutzung von TYPO3
umständlicher. Schade, dass die drei Save-Buttons weggefallen sind.
Auch das Kopieren und Verschieben von Content-Elementen über Seiten
hinweg ist umständlicher geworden und funktioniert nicht mehr "richtig".
Wenn ich im Page-Modul über das Content-Element-Menü zum Kopieren
markiere, dann erwarte ich, dass ich das Element auf einer anderen Seite
einfügen kann. Nach meinen Erfahrungen ist das Kopieren über das
Clipboard im Listmodul derzeit der einzige Weg, um Datensätze über
Seiten hinweg zu kopieren.
Richtig nervig ist, dass man bei einem Backend-Reload automatisch immer
auf der Startseite landet. Das System merkt sich weder das zuletzt
genutzte Modul noch die zuletzt bearbeitete Seite. Auch die Pflege von
längeren Content-Seiten im Page-Modul ist nervig. Zum Beispiel würde ich
nach dem "Ausblenden" eines Content-Elements erwarten, dass ich danach
an der gleichen Stelle weiterarbeiten kann. Leider wird man nach jedem
Ausblenden wieder auf den Start der Seite zurückgeschickt.

Aber diese Kleinigkeiten werden vielleicht in Laufe der zukünftigen
Entwicklung behoben werden. Insgesamt ist TYPO3 im Backend popiger
geworden. Auch seien hier ausdrücklich die neuen Vorteile von der
Siebener-Version genannt. Zum Beispiel erleichtern die Hinweise auf
fehlerhafte Queries bzw. auf fehlerhafte Content-Elemente im Frontend
wesentlich das Debuggen während der Entwicklung.

Dieter


P.S. Mit der 7-Version hat TYPO3 gute Fortschritte gemacht und ich
möchte den Entwicklern ausdrücklich für ihre Arbeit danken. Mit Eurer
Arbeit bleibt nach meinem Eindruck TYPO3 unter den
Content-Management-Systemen weiterhin das, was Mercedes früher einmal
bei den Automarken war - eine solides, sehr gut durchdachtes und
effizientes Produkt.
 


-- Dr. Dieter Porth - Mein kleines TYPO3-Labor: http://www.mobger.de/