25 Reaktionen zu “Wohin geht die Reise?”

Kommentare abonnieren (RSS) oder TrackBack URL

So ganz stimmt dies nicht.

Die Namespaces wurden schon mit 6.0 eingeführt, zusammen mit FAL (File handling Abstraction Layer). Dabei wurden alle Klassen umbenannt und dabei an passende Orte verschoben.
Dadurch kann man zum ersten mal im TYPO3 Core die Klasse für eine Aufgabe anhand der Namenskonventionen finden und vice-versa.
In 6.2 wurden nur die alten Dummy-Dateien entfernt, sodass Extensions nun den seit 4.3 (!!!) verfügbaren Autoloader zwingend nutzen müssen.

Bzgl. Flow, Neos:
TYPO3 Flow ist ein eigenes Produkt und ganz Framework (im Gegensatz zum CMS, das beides ist). TYPO3 Neos ist ein CMS Aufsatz auf Flow, welcher sich besonders auf verzweigte Datenstrukturen konzentriert (Node-Tree). In CMS gibt es ja nur Pages und Records, in Neos wird es nur noch Nodes, geben, die jedoch auch immer als Elternode (Page in CMS) fungieren können.

In 7.0 soll Flow teilweise in CMS integriert werden. D.h. es sollen insbesondere die redundanten Code Teil durch die richtigen Flow Funktionalitäten ersetzt werden. Dies betrifft insbesondere das Caching-Framwork und Fluid, da dieser Code quasi eine 1:1 Kopie des Flow Codes ist.
Natürlich sollen dann nach und nach weitere Komponenten folgen.
Darüber hinaus kann man dann Flow Pakete (zumindest Code mäßig) in CMS nutzen.
Man könnte dann also TYPO3 Neos zum Frontend Editing verwenden.
So werden die verschiedenen TYPO3 Produkte also zusammenwachsen, wie es ja auch seit dem Berlino Manifesto angeregt wird.

Zuerst kommt jedoch nochmal eine LTS mit erheblichen Verbesserungen des zugrunde liegenden Codes, sodass einer 3-(oder sogar mehr) jährigen Wartung nichts im Wege steht.

Philipp Gampe am 01. August 2013 um 17:52

Wo genau hat er was anderes zu Namespaces geschrieben?

Mathias Schreiber am 02. August 2013 um 00:02

Die zeitliche Abfolge stimmt nicht. Das Namespacing wurde nicht wegen Flow eingeführt. Auch die Struktur ist nicht wegen Flow so, sodern primär MVC.
Außerdem wurden nicht für die 6.2 die Dateien verschoben, sodern schon für die 6.0. In 6.2 wurden nur die Dummy Dateien für alle include(_once) Aufrufe wieder entfernt.

Durch das Namespacing kann man jetzt aber über solche Stunts wie die Flow Integration nachdenken. Dies war vorher einfach unmöglich.
Außerdem ist es jetzt möglich, TYPO3 CMS Code mit anderen Code zu kombinieren, e.g. gleichzeitig Drupal und TYPO3 CMS zu laden um irgendetwas Abgefahrenes zu machen.
Diese Möglichkeit bestannt vor der 6.0 einfach gar nicht.

Philipp Gampe am 02. August 2013 um 13:48

„Und wenn alle Stricke reißen, könnte es auch eine Extension geben, die auf TYPO3 6.2 installiert wird, um alte Extensions dennoch auf der 6.2er Version zum Laufen zu bringen.“

wenn in der aktuellen Alpha2 eine leere Datei unter typo3/sysext/cms/t3lib/
class.tslib_pibase.php angelegt wird, laufen alte Extensions ohne Problem. Ob das jetzt so gewollt ist muss wohl das Core Team entscheiden.

mario am 02. August 2013 um 16:16

@mario: Oder man schmeißt die require(_once) einfach raus. Den Autoloader gibt es ja erst seit 4.3 😉

Philipp Gampe am 03. August 2013 um 00:55

@Philipp das kann man auch machen, aber ein einfaches anlegen ist schneller gemacht als 10 Ext. anzupassen.

Ich sehe das eher als Migration Feature in der 6.2!?

mario am 05. August 2013 um 09:16

Das ist ein Feature 🙂

Die Extensions hätten schon vor fünf Jahren angepasst werden sollen.

Dafür ist t3lib jetzt endgültig Geschichte.

Philipp Gampe am 05. August 2013 um 09:31

Ich verstehe das Paradigma nicht so ganz.
Wortlaut ist ja, dass eine Klasse mit 100 Funktionen unübersichtlich ist.
80 Verzeichnisse mit 80 Klassen, die je eine oder 2 Funktionen haben, soll übersichtlicher sein.

Für mich ist das austäuschig.

Wie aufwändig das letztendlich ist, es umzubauen, wird sich zeigen.
Die wirklich leidtragenden sind leider die, die sich nah am Core aufgehalten haben, API Funktionen genutzt etc.

Und es zeigt sich in der Praxis, dass es sehr schwer bzw. oftmals unmöglich ist, diesen Aufwand für ein Update zu rechtfertigen.

Ich habe Verständnis dafür, dass man da am Code was machen will.
Mein Vorschlag wäre allerdings, sich ab jetzt wieder auf die Aufgabe eines CMS zu konzentrieren:
Probleme von Redakteuren beheben.

Nach meinem Wissensstand war das ja vorher nicht möglich bzw. nicht sinnvoll, da die Codebasis das ja nicht her gab.

Mathias Schreiber am 05. August 2013 um 09:38

Dafür ist t3lib jetzt endgültig Geschichte.
Und das ist ein Vorteil, weil: …. ?

Peter am 05. August 2013 um 16:21

Und das ist ein Vorteil, weil
konnte mir auch keiner beantworten, aber es scheint wichtig zu sein.
Ich selbst hab t3lib_div in bestimmt 50 nicht-TYPO3-Projekten als Swiss Army Knife drin.
Jetzt muss ich das wahrscheinlich in ein Vendor Package packen… also generell mit sowas arbeiten, selbst wenn ich das gar nicht will.
So schaut halt die schöne Freiheit aus.
Auf der anderen Seite sei gesagt, dass WENN man Package basiert entwickeln will (was man sich ja jetzt nicht mehr aussuchen darf, sondern diktiert bekommt), macht das echt Spaß.

Mathias Schreiber am 05. August 2013 um 16:43

„Wortlaut ist ja, dass eine Klasse mit 100 Funktionen unübersichtlich ist. 80 Verzeichnisse mit 80 Klassen, die je eine oder 2 Funktionen haben, soll übersichtlicher sein.“

Ich tippe auf die jeweils präferierte IDE: PHPStorm (und alle JAVA-IDEs) kann wirklich gut mit vielen Ordnern und kleinen Dateien umgehen. Meine alte IDE konnte besser mit großen Dateien mit vielen Funktionen umgehen. Die ist jetzt nicht mehr zeitgemäß … wobei sich für mich die Henne-Ei-Frage stellt: Paradigma oder IDE? 🙂

Wenn ich mir den fileadmin-Ordner des Introduction Package anschaue, so wird eine IDE auch für Integratoren zwingend. Die konsequente Extbase-Schreibweise (Ordner in UpperCamelcase, Dateien in LowerCamelcase) bei TS-Dateien wirkt jedenfalls überzeugend. Dabei könnte man Dateinamen eigentlich weglassen, schließlich heissen fast alle Dateien setup.ts. Bis auf die paar constants.ts natürlich, aber es wäre ja nur konsequent dafür auch noch Ordner einzuführen. Dann könnte man jede Datei einfach nur index.ts nennen.

Das ist schon irgendwie irre:
fileadmin/default/TypoScript/Block/ContentLeft/setup.ts
und darin diese beiden Zeilen Code:
lib.contentleft = COA
lib.contentleft.20 < styles.content.getLeft
Hat was 🙂

Peter am 05. August 2013 um 17:19

@Matthias: t3lib_div ist nicht gleich t3lib. Lag da zwar drin, aber die Funktionen von t3lib_div gibts noch, allerdings in der Klasse GeneralUtility. Ich bin mir nicht 100%ig sicher, aber so weit ich weiß, funktionieren die Aufrufe dieser Methoden nach wie vor, und zwar ohne Änderung, sie werden nur umgelenkt auf die neue Klasse. Was nicht mehr geht, ist das Includieren von Klassen über include() oder require(), aber das musste man ja mit der t3lib_div nicht. Ich meine, bei den meisten Extensions sollte es ausreichen, diese includes durch die Autoload-Funktion zu ersetzen. Probleme werden ber mit deprecated-Methods auftreten, nicht nur mit TYPO3 sondern auch mit PHP 5.4. Da gibts einige Extensions, die deswegen hops gehen.

Beispiel tt_news, diese Zeile:
$t3version = t3lib_div::int_from_ver(TYPO3_version);
in der ext_localconf.php
führt zu diesem Fehler im Backend von TYPO3 6.1:
Fatal error: Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::int_from_ver() in /Users/peter/Sites/typo3_61/typo3conf/ext/tt_news/ext_localconf.php on line 48
Heißt, dass die richtige Klasse aufgerufen wird, es dort die Methode int_from_ver aber nicht mehr gibt.

Peter am 05. August 2013 um 17:57

schönes Beispiel eigentlich.
Ich hab selbst mit Rupi an diesem „Fehler“ gesessen.
Lösung ist jetzt, dass man (performance-mäßig teuer) andauernd prüfen muss, ob eine Funktion sich noch an der Stelle befindet, wo sie mal war.

Ich hab nix gegen Breaking Changes, aber bei so Brot-und-Butter Funktionen, die man benutzt, weil man es eben besser machen will als die Jungs, die gar nichts testen und dir einfach nur ne Extension himschmeissen, sollte 2-10x nachgedacht werden, ob die jetzt wirklich an eine andere Stelle müssen.

Wenn man in Ruhe drüber nachdenkt…
Die zentrale Funktion, um rauszufinden, in welcher TYPO3-Version man ist, darf man nie nie nie nie woanders hin bewegen, da sie sonst jeglichen Sinn verliert.

Mathias Schreiber am 05. August 2013 um 18:05

@Peter @Mathias ist Funktion ist seit 4.6 (also auch in 4.5, 4.7, 6.0) deprecated gewesen. Wie lange sollen wir den Altlasten mitschleppen?

Selbst in 4.5 seht schon ein Hinweis:
t3lib_div::int_from_ver
Returns an integer from a three part version number, eg ‚4.12.3‘ -> 4012003 This method will be deprecated in TYPO3 4.6. You are encouraged to start using t3lib_utility_VersionNumber::convertVersionNumberToInteger() instead

Man muss tatsächlich nur die require/include Aufrufe entfernen, um die meisten Extensions lauffähig zu bekommen.
Und tatsächlich macht PHP 5.4 mehr Probleme als TYPO3 CMS.
Außerdem sind die TYPO3 Entwickler in diesem Punkt einfach (IMHO) zu verwöhnt.

Philipp Gampe am 05. August 2013 um 18:31

Wie lange sollen wir den Altlasten mitschleppen?

Gute Frage, gute Antwort:
2 LTS lang.
Schaut man sich die Verteilung an, spielt nämlich 4.6, 4.7 und 6.0 nicht wirklich eine Rolle im Markt.
Daher ist dies eine Altlast, die – wenn man sich mit dem Markt beschäftigt – durchaus mitgeschleppt werden sollte, da sich viele ernsthafte Kunden nämlich von LTS zu LTS hangeln werden.

Und der Hinweis mit 4.5 ist leider nicht hilfreich, wenn man mehr Versionen abdecken möchte.
Hier wird ein Riegel vorgeschoben, weil irgendjemand lieber Ordner als Dateien hat.
Eine echte Begründung jenseits von „Ich find das aber schöner so“ kam leider bisher noch nicht.
Sollte es die geben, mag die Situation anders aussehen, wobei ich es bei diesem Beispiel stark anzweifle.
Außerdem sind die TYPO3 Entwickler in diesem Punkt einfach (IMHO) zu verwöhnt.
Da schätzen wir uns glücklich, dass Du entscheidest, wer verwöhnt ist und wer nicht.
Oder was „Verwöhnen“ bedeutet.
Was du „verwöhnt“ nennst, nennen viele meiner Kunden „planungssicher“.

Du siehst, die Meinungen gehen auseinander und deswegen ist es für alle Beteiligten kriegsentscheidend, zu sprechen.
Dieses Beispiel ist ein Grund dafür, warum eine Art Product Board notwendig ist.

Und bitte auch nicht (wie so oft) falsch verstehen:
Es geht nicht darum, Refactoring zu verbieten.
Es geht nur darum, mehr Weitblick bei den Auswirkungen zu zeigen.
Wer auch immer diese Funktion weg geschoben hat, hätte doch nur einmal realistisch schauen müssen, was die LTS „gebracht“ hat.
80% Marktanteil der bekannten Installationen.
Dann muss man nicht lang nachdenken, um zu sehen, dass LTS ein Erfolg war und ist.
Von dort aus bewegt man sich mental weiter zu „ok.. was erhoffen sich Nutzer von LTS? Ah… wir machen breaking changes… das ist ok… wie sorgen wir dafür, dass Breaking Changes geprüft werden können? Jo, wir behalten die eine Funktion (und falls es noch mehr gibt, die eine solche Prüfung sicherstellen auch die) bei und sterben den einen, kleinen Tod.

So würde man das im Profi-Segment machen.
Wir machen’s leider nicht und daran sollte man etwas ändern.

Mathias Schreiber am 05. August 2013 um 18:48

@Matthias:

Ich habe gerade eine pi_base(!)-Extension von mir unter 6.2 alfa getestet.

1. pibase funktioniert, die Klasse wird problemlos erweitert.
2. ich hatte in einer flexform eine userfunc, die musste ich über den autoloader einbinden. Das war einfach.
3. ein schöner Fehler war in substituteMarkerArray: Ich hatte als 4. Parameter das hier einen leeren String – geht nicht mehr in PHP 5.4, das muss jetzt array() sein. Schlampig programmiert von mir, was PHP 5.4 nicht mehr durchgehen lässt.
4. tx_gwisem_pi1_wizicon ist etwas blöd, da scheint readLLXMLfile nicht mehr zu funktionieren. Ich habe mir aber eine andere Schreibweise bei der news-Extension abgeschaut, das geht in 5 Minuten – pro Plugin.
5. in einem der drei Plugins verwende ich noch die alte Mailklasse, die seit 4.6 obsolet ist. Das muss ich austauschen, aber das habe ich in den meisten meiner Extensions schon gemacht; das dauert so etwa 15-20 Minuten.

Fazit: Auswand ist da, hält sich aber in Grenzen. Ich schätze für diese Extension mit drei Plugins etwa 1 bis 1,5 Stunden.

– das Erweitern der pi_base-Klasse geht einfach.
– das Einbinden von anderen Klassen geht über den Autoloader wirklich einfach.
– die von mir verwendeten API-Aufrufe aus der t3lib_div funktionieren alle noch.
– tx_gwisem_pi1_wizicon muss angepasst werden, aber begrenzt
– Namespacings braucht es nicht.

Die größte Änderung ist ohne Zweifel die neue Mailklasse, da die aber schon seit 4.5 existiert, habe ich die bei den neuen Extensions eh schon verwendet. Und der Aufwand, die umzuschreiben hält sich in Grenzen. Ich schätze mal, ältere Extbase-Extensions anzupassen dürfte aufwändiger sein.

Das war schon mal ein ganz optimistischer Anfang, würde ich sagen. Ich musste letztens eine eigene PHP-Programmierung von PHP 4 auf PHP 5.4 hochheben, da war deutlich mehr zu machen 🙂

Peter am 05. August 2013 um 20:21

PS: an den Blog-Gestalter: das Theme hier erinnert mich immer an die alten Monitore mit weisser, gelber oder grüner Schrift auf schwarzem Grund. Die waren extrem ermüdend … Die Schrift hier ist das auch. Insbesondere die Kommentare sind für mich kaum lesbar, der Text beginnt nach 2/3 Zeilen regelrecht zu flimmern. ich muss mir den Text rauskopieren um ihn lesen zu können …

Peter am 05. August 2013 um 20:43

für sowas gibt es „ctrl +“ bzw „ctrl mousewheel“.

kommentator am 05. August 2013 um 21:32

Nur zur Information: int_from_ver() wurde in 6.x wieder eingeführt, um genau diese Probleme zu vermeiden:
https://git.typo3.org/Packages/TYPO3.CMS.git/commit/160ddfeab23a708592fd8de8d3074da69bb8ef27

Markus K am 06. August 2013 um 09:04

Hey Peter, Hey Komentator, das ist in Arbeit wird aber noch ein paar Tage dauern. Ein neues Design liegt bereits in der Schublade 🙂 Besserung ist in sicht…

Tim Lochmüller am 06. August 2013 um 09:44

Ein Hoch auf Helmut für den mutigen und vor allem richtigen Schritt

Mathias Schreiber am 06. August 2013 um 09:52

Wir haben bei einigen Projekten unglaubliche Probleme mit Templavoila, RealURL etc gehabt, weswegen wir uns bei bestimmten Aufgaben auch auf 4.5 LTS festgelegt haben. Sind aber auch gespannt auf den Übergang. 🙂

Browserwerk Internetagentur - Gerrit am 06. August 2013 um 20:29

Ein interessanter Beitrag und eine interessante Diskussion.
Ich bin ein bekennender Technikfan. Daher kann ich gut nachfühlen, dass die Entwickler Refactoring eine hohe Priorität einräumen. Die hier propagierten künftigen Möglichkeiten klingen gut, wobei es mir jetzt noch erschwert, ob ich meinen Webseitenrelaunch (bei dem alle Extensions selbst entwickelt werden) auf TYPO3 CMS Basis mache oder schon Neos.

Ich hoffe, dass
– künftig wieder mit jeder neuen TYPO3 Version Features ausgeliefert werden, die dann vornehmlich den Redakteuren dienen (also eine Balance aus Refactoring & Features) – Ein Feature kann auch eine Komfortfunktion sein – das verbessern der Abläufe aktueller Funktionen etc.
– es eine klare Zielgruppentrennung zwischen Neos und CMS geben wird und gute Infoseiten, die einfach mit Beispielen erklären, was wofür geeignet ist. Meinetwegen ggf. dann auch, wie die verschiedenen TYPO3 Produkte zusammenwirken (können).
– ein überarbeitetes Extension Management, die RIchtung in die es geht, gefällt mir.
– TYPO3 Neos bald stable wird. 🙂

Extension Management:
Da ich ein Fan von Breaking Changes bin im Sinne: Ich hasse es aus Kompatibilitätsgründen unglücklich zu programmieren / Workaround zu nutzen / Code-Relikte beizubehalten. Ich fände es gut, wenn der Extension Manager dafür die Parallelentwicklung unterstützen (sagt es mir bitte, falls er es schon kann) würde im Sinne:
Ich kann eine Extension entwickeln und mit hochziehender Versionsnummer, können alte TYPO3 Installationen, weiterhin die alten Versionen runterladen und ihnen wird diese auch direkt angeboten, und nur ein Hinweis, dass es eine neuere gibt, die aber nur für neuere TYPO3-Versionen ist. Damit sollte es dann möglich sein, alte Extensions nur für Sicherheitsfixes für alte TYPO3-Versionen zu aktualisieren. Zusätzlich müsste markierbar sein, wenn alte Extensionsversionen für alte TYPO3-Versionen eben noch gepflegt werden (ganz, nur Sicherheitsupdates o.ä.) mit einer kleineren Versionsnummer. Ich fand das bei Powermail schon verbesserungswürdig. Ansonsten hat man als Entwickler ja nur die Möglichkeit, eine neue Extension zu machen, doch das finde ich aus „Marketinggründen“ unglükclich.

Hauke am 13. September 2013 um 12:51

Weiß Jemand, ob bei der 7.4.0 auch noch alte pi_base Extensions laufen wie in 6.2?

Danke und Grüße

Kevin am 17. September 2015 um 17:25

Ja… wenn ordentlich Namespaces benutzt werden. Aber laufen tun diese…

Tim Lochmüller am 17. September 2015 um 18:12
Ein Kommentar hinterlassen


 Name


 Mail (wird nicht veröffentlicht)


 Website

Bitte beachten sie, dass ihr Kommentar möglicherweise erst freigeschaltet werden muss.

Kategorien

Archiv (Quick)

Dezember 2017
M D M D F S S
« Nov    
 123
45678910
11121314151617
18192021222324
25262728293031