[TYPO3-german] eigenes extbase Query im Domain Repository

[Stephan Schuler]

Hallo Nicolas.

Das sieht mir etwas holprig aus, und zwar an mehreren Stellen.

Erstens fehlt mir Dein Model vom Typ UserList, das solltest Du mit veröffentlichen, damit wir das Gesamtkunstwerk beurteilen können.

Dann glaube ich nicht, dass Dein Objekt UserList heißen soll, sondern User. Immerhin liest Du aus der Tabelle fe_users, und eine Zeile daraus ist ja nicht eine Liste an Benutzern, sondern ein einziger Benutzer.

Weiterhin solltest Du von den zugehörigen TYPO3-Basisklassen ableiten:
• \TYPO3\CMS\Extbase\Domain\Model\FrontendUser
• \TYPO3\CMS\Extbase\Domain\Repository\FrontendUserRepository

Bis hier hin ist alles optional. Du solltest das zwar trotzdem ändern, weil Du Dir sonst das Leben sehr schwer machst, wenn es darum geht, Deinen Code mit einer beliebigen Anfänger-Dokumentation zu vergleichen. Aber streng genommen kannst Du den Teil auch bleiben lassen, wenn Du weißt was Du tust.

Ab hier dann der Teil von dem ich glaube, dass er aktuell dein Problem darstellt.

Wenn Du dem Objekt weitere Properties gibst, kannst Du entweder die Schreibweise der Datenbankspalte mit der Schreibweise der Objekt-Property identisch halten. Dann sollte die Zuordnung autoamtisch funtionieren. Allerdings läufst Du Gefahr, dass Du einen Namen verwendest, den auch andere verwenden, oder durch ein Update vom Core verwendet wird. Sagen wir $mobile für die Handynummer. Niemand garantiert Dir, dass Du den Namen für Dich hast und dass das nicht in einem halben Jahr vom Core geliefert wird, oder von einer anderen Extension die Du einsetzt.
Alternativ kannst Du die Datenbankspalten mit Deinem Extension-Key prefixen, sie also nicht „mobile“ sondern „deinextensionkey_mobile“ nennen. Wenn Du in Deinem Extbase-Model trotzdem die Property $mobile haben möchtest und nicht $deinextensionkeyMobile, funtioniert die Zuordnung nicht automatisch, sondern Du musst sie per TypoScript konfigurieren.

Welche Variante davon Du verwendet hast und was nicht kann ich nicht beurteilen, weil Du weder deine Modelklasse noch Dein TCA noch Dein SQL veröffentlich hast.

https://docs.typo3.org/typo3cms/ExtbaseFluidBook/6-Persistence/4-use-foreign-data-sources.html
So etwa sollte man das konfigurieren, ich spreche von „columns“.

Dann wäre es ganz super, wenn Dein Repository einfach wüsste, mit welcher Datenbanktabelle es umgehen soll und welches Objekt es daraus erzeugen soll. Hierzu dient dann der übrige Teil des Links den ich gerade geschrieben habe. Hauptsächlich spreche ich von „MyVendor\MyExtension\Domain\Model\Person“, also dem Klassennamen, und „tableName = tt_address“, also der Zuordnung, dass diese Model-Klasse in dieser Tabelle zu finden ist.
Wenn Du diesen Teil weglässt, geht Extbase davon aus, dass der Klassenname des Models auf den Tabellennamen abgebildet wird und anders herum. Das ist bei „fe_users“ natürlich nicht der Fall, also brauchst Du das Setting.

Anstelle von „plugin.tx_myextesnion“ kannst Du auch „plugin.tx_extbase“ verwenden, dann gilt dieses Setting global für alle Extensions.

Nun steht da noch ein „recordType = \MyVendor\MyExtension\Domain\Model\Person“. Das ist ebenfalls wichtig, weil der „fe_user“ in mehreren Types daherkommt. Der Type steht in einer bestimmten Spalte in der Datenbank und gibt an, welche Klasse verwendet werden muss, wenn das Objekt aus der Datenbank gelesen wird.

Als letzten Punkt solltest Du das SQL-Statement vermeiden wo es nur geht. Du machst Dir nur das Leben schwer, und Du verzichtest auf ein paar Dinge von denen jegliche Doku ausgeht, dass Du Dich darauf eigentlich verlassen kannst.
Ein super Beispiel ist Dein „setRespectStoragePid“. Das hat natürlich überhaupt keine Auswirkung, wenn Du das Statement als SQL-String vorgibst.
Ein zweites super Beispiel ist Deine Einschränkung auf die usergroup. Sollten Deine Frontend-Benutzergruppen mal auf 50 und mehr anwachsen, sind die Gruppen 50 bis 59 alle in Deinem Like-Query enthalten.

Was Du eigentlich haben möchtest, ist:
> $query = $this->createQuery();
> return $query->matching($query->in(‘usergroup’, 5))->execute();

Noch schöner wäre, wenn hier nicht “5” stehen würde, sondern ein Objekt vom Typ FrontendUserGroup. Insbesondere wenn das ggf. ein Wert ist den Du per GET- oder POST-Parameter übergeben bekommst, willst Du ihn auf jeden Fall vom PropertyMapper in ein Objekt verwandeln lassen anstelle des Integers.

Das Ordering kannst Du entweder auch dem Query mitgeben, oder aber Du setzt das Ordering als DefaultQuerySetting im Repository, dann sind Deine Models immer nach Name sortiert.

P.S.: Wenn Du viel Code teilen möchtest, solltest Du Dir überlegen, ob Du nicht lieber ein Gist verlinken willst anstatt hier inline einen Code in die Mail zu packen. Im Idealfall packst Du Deine komplette Extension in ein Gist. Nachdem wir das außerhalb dieser Diskussion nicht weiter brauchen, kann das gerne anonym sein. Solange Du nur nicht hier 1000 Zeilen Code inline einbindest oder anfängst, 10 Dateien anzuhängen.

Beste Grüße,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de



----------------------------
Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt