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
