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.ga...@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@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/ _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
