9 Reaktionen zu “TYPO3 Autoloader – Teil 2”

Kommentare abonnieren (RSS) oder TrackBack URL

Hi,

ich finde es super, dass ihr so viel Energie in die Entwicklung steckt. Macht weiter so!

Gruß, Tobi

Tobi am 21. August 2014 um 21:38

Hi!

Bezüglich FCE: Ich würde mir wünschen, dass die Energien gebündelt werden => Schaut euch die Mask Extension an.

Schöne Grüße
Markus

Markus Klein am 21. August 2014 um 23:34

Im Rahmen dieses Beitrags hatte ich einmal ein Blick in Mask geworfen: https://typo3blogger.de/typo3-mask-eine-neue-templating-alternative/

Wo gibt es den den Quelltext, sodass man diese einmal beäugen kann? Grund Idee ist schon einmal besser als bei den anderen Alternativen. Ich werde die Entwicklung verfolgen…

Tim Lochmüller am 22. August 2014 um 09:01

Kurz auch noch mein Senf:
Mask ist bisher tatsächlich die einzige öffentlich auffindbare FCE-Alternative, die *nicht* auf flexform zur Datenspeicherung setzt.
Selbst das häufig benannte „Monster“ fluidtypo3(flux, fluidcontent, ehemals fedext) versagt an dieser wesentlichen Stelle.
DCE ist im Handling ziemlich ausgereift, speichert aber ebenfalls per flexform und ist durch die rein DB-basierte Speicherung der Felddefinitionen/“FCEs“ sehr unhandlich bzgl. Deployments.
Ich möchte den Wunsch von Tim auf Einsicht in die alpha doppeln, zwecks Energiebündelung…

Ben am 22. August 2014 um 09:29

Nach welcher Regel erfolgte denn die Wahl der folgenden Schreibweise „Resources/Private/Php/eID/“ für PHP und eID?

Ich bin stets bemüht Abkürzungen und Wordings für Eigennamen korrekt in Pfaden auszuweisen damit das Ganze schön intuitiv bleibt.

TCA, TypoScript, PHP, EID, FlexForms… Schon der Extension Builder schlug TypoScript und TCA vor. Warum dann Php anstatt PHP. Warum eID anstatt EID oder Eid? Verwirrung… Irgendwann braucht man für das Wording in den Pfaden ja ein Nachschlage-Handbuch, wenn davon das Autoloading abhängt.

Oder verstehe ich da gerade was falsch? Ich sehe hier einen Stolperstein, der bei Unwissenheit für eine Mühsal in Sachen Fehlersuche sorgen kann…

Andy am 26. August 2014 um 13:15

Hey Andy, da gebe ich dir Recht. Bei den Punkten, welche vom Core vorgegeben werden (Beispiel: Configuration/TCA) regeln wir das Laden dementsprechend. Bei anderen Punkten ist mir keine GuideLine bekannt, welche vorsieht wie ich „eID“ in einem Pfad zu schreiben habe (alternative wäre „ExtensionId“) zum anderen wo diese abzulegen sind. Oder? Was wäre den dein Vorschlag? Da es keine 1:1-Klasse-Datei Beziehung ist, sondern ja auch Aufrufe in der Datei sind, finde ich den Ordner „Classes“ undpassend. Resources/Private hatte sich für mich angeboten, da es von außen nicht aufzurufen ist und so auch sichergestellt ist, dass keiner den Pfad direkt aufruft. Neue Ideen und Korrekturen sind gern gesehen! Wir können auch mehrere Pfad prüfen bzw. jetzt noch wechseln und deprecated Meldungen generieren?!?! Grüße, Tim

Tim Lochmüller am 26. August 2014 um 14:15

Hallo ihrs,

ausgehend von der bereits Einzug gehaltenen Nomenklatur seitens Extbase und Flow, schlage ich vor Abkürzungen entweder strikt dem UpperCamelCase zu unterwerfen, oder aber strikt zu uppercasirifizieren.

Mein konkreter Vorschlag: https://gist.github.com/anonymous/0df7f22298f207f8f0fa

Extbase und Flow geben ja schon ViewHelpers vor. Der Extension Builer hat uns TCA eingebläut. Das gibt uns die Flexibilität Eigennamen hervorragend zu handhaben, sowie Akronyme.

FlexForms, TypoScript, JavaScript, usw. usf.
LESS, PHP, SCSS, SQL, CSS, JS, etc.
Abkürzungen kann man ja dennoch dem UpperCamelCase unterwerfen: Img, Pic, etc pp.

Ich bin übrigens deiner Meinung, dass die eID-Scripts eher unpassend für Classes/ sind. Zusammen mit den dran gehookten Content Element Wizard Icons (wizicon), kann man die gut in PHP oder Lib werfen. Wobei PHP im Kontext von Private Resources eher Sinn macht – denn da kann noch so viel anderes liegen…

Andy am 26. August 2014 um 15:44

Hallo Tim,

zu dem Pfad für eID-Skripte habe ich dann aber auch nochmal eine Rückfrage: In der TYPO3 CMS CodingGuidelinesReference steht für den Ordner „classes“: „Directory for the PHP files of the extension“ – das würde für mich bedeuten, dass auch die eID-Scripts dort hinein gehören. Natürlich kann man sich an dem Namen „classes“ stören, aber warum gibt es den Ordner dann überhaupt, wenn man die PHP-Klassen doch auch gleich alle unter Resources/Private/ ablegen könnte?

Die von Andy genannten Icons gehören – als Bild-Dateien – natürlich in den Resources-Ordner, aber das ist ja gerade die neue Struktur, dass die ganzen Dateien eher nach Dateityp als nach funktionalen Modulen gruppiert sind (sonst müsste man konsequenterweise nämlich auch die Template-Dateien jeweils in einen Ordner mit der jeweiligen PHP-Klasse der View ablegen).

Da jetzt für eID-Skripte wieder eine Ausnahme von der Regel zu schaffen führt in meinen Augen eher zu Verwirrung als zu einem echten Mehrwert.

Thx4Comment

Hannes Gesmann am 13. Oktober 2014 um 10:28

tl;dr (Classes = nur Klassen, keinen Code ausserhalb von Klassen)

Hallo Hannes, das ist eine durchaus berechtigte Annahme/Anmerkung. Ich entwickel meine Extensions ebenfalls mit der Berücksichtigung das in Classes Klassen liegen. Das Problem ist, dass ein eID Script eine Klasse instanziiert und ausführt. Dieses verhalten erwarte ich nicht, wenn ich eine Klasse im „Classes“-Ordner liegen habe, da man zum einen nicht davon ausgeht, dass wenn man eine Klasse lädt auch gleich etwas ausgeführt wird (wie bei einem eID script) und zum anderen das Script von aussen auch über den Pfad aufgerufen werden kann. Dadruch dass es in Resource/Private/ liegt, lässt es sich von aussen nicht mehr aufrufen (nur noch über /?eID=KEY). Hinzu kommt, dass das eID Script selbst nur ein 2-Zeiler sein sollte (Service-Klasse instanziieren + Methode aufrufen). Die Service-Klasse wiederum sollte natprlich in dem Classes-Ordner strukturiert werden… Wobei dies mehr ein persönliches Empfinden ist und nicht über die CGL 100% abgedekt wird (dort steht ja auch, dass PHP in Resources/Private nicht ausgeschlossen ist, wenn es 3rd Party teile sind)…. Würde der eID Mechanismus z.B. eine Klassen->Methoden Konfiguration benötigen und nicht einen Pfad, dann würde ich das eID Skript selbst auch direkt im Classes Ordner ablegen. Grüße, Tim

Tim Lochmüller am 13. Oktober 2014 um 14:03

Kategorien

Archiv