[TYPO3-german] extbase Objekte sehr langsam

[Michael Stein]

Hallo Dieter,
vielen Dank für die Ausführliche Antwort.
Aber irgendwie ist das nicht das was ich brauche.
Das Problem liegt nicht bei fluid sondern bei extbase.
So schrecklich kompliziert ist das Modell nicht.
Es ist eine Erweiterung von fe_users und referenziert im wesentlichen 
countries und fe_groups.
company ist ein n:1 nach fe_groups.

Ich hole die Liste so:
$query = $this->createQuery();
$query->matching(
	$query->in('company', $listOfCompanies)
);
$results = $query->execute();

wenn ich das mit 
$results = $query->execute(true);
mache, ist die Liste fix da.
Aber wenn extbase anfängt daraus Objecte zu bauen, ist alles verloren.

Das mit dem Dataprovider würde mich aber trotzdem interessieren.
Wo kann ich dazu mehr lesen?

Gruß
Michael




On Thu, 01 Sep 2016 18:11:42 +0200, Dr. Dieter Porth wrote:

> Hallo Michael
> 
> Variante a)  (mit Dataprovider im Fluidtemplate)
> 
> Dein Modell ist gut durchdacht. und du kannst nach einer DB-Abfrage alle
> Elemente in einem Array übergeben
> 
> 
> Variante b) (mit Dataprovider im Fluidtemplate)
> 
> Dein Modell ist weniger optimal. du musst aus mehreren DB-Abfragen ein
> Object zusammenbauen, welches du dann rausrendern kannst.
> 
> bis fünfundert sechhundert Datensätze funktioniert dies ganz gut, wenn
> man nicht für jden Datensatz ein Partial aufruft.
> 
> 
> Variante c) (unangenehme Lösung)
> 
> Dein Modell ist eher schlecht und du brauchst für jeden Datensatz eine
> eigene DB-Abdfrage plus Rendering. Dann ist dir nicht zu helfen und du
> solltest dein Modell neu bauen; denn es passt nicht zu deinen
> Anforderungen.
> 
> 
> Variante d) (Multi-Lösung)
> 
> Du nutzt einen Varinsh, um die Seiten  per Server-Cache
> zwischenzuspeichern
> 
> Variante e) (Einzellösung)
> Du cachst die gesamte Seite und schreibst einen eid-Meachnismus, der die
> Seite einmailg rendert und bei Anfrage die gesamte Seite als HTML
> ausliefert.
> 
> Alle Lösungen haben ihre Vor und Nachteile, was die Aktualität, die
> Flexibilität und den Programmieraufwand angehen.
> 
> 
> Variante f) (viewhelper)
> Dir ist der Dataprovider zu kompliziert und du kennst dich mit dem
> Viewhelper aus. Dann löst alles im Viewhelper und ignorierst die
> Konvention, dass im View die Viewhelper sich nur um die korrekte
> Viewdarstellung kümmern.
> 
> 
> Variante g) (Ajax)
> Du lädst deine  schrittweise 300 Objekte per Ajax nach und
> untergleiderst deinen Kuchen in mehrere Stücke. Das erfordert natürlich
> ein jeweils auch die Anpassungen deiner Pagenierung.
> 
> Variante h (Java-Spkript-paginierung)
> Du nimmst nur deine Liste mit den Elementen und suchst für die
> Pagenierung eine Javascript-Lösung.
> 
> ...
> 
> Mit besten Grüßen
>     Dieter
> 
> Am 01.09.2016 um 11:41 schrieb Michael Stein:
>> Hallo zusammen,
>> ich habe ein typo3 6.2 am Start mit einer Extension die eine Liste von
>> Records erzeugt.
>> Die Objecte referenzieren ein paar andere Tabellen.
>> Das funktioniert alles ganz gut. Aber ab 300 Objekten wird der
>> Listenaufbau sehr langsam und das ganze ist extrem Speicherintensiv.
>>
>> Kann ich irgendwie verhindern, dass immer das ganze Object zusammen
>> gebaut wird?
>> Mir reichen für die Liste die Einträge aus dem Basis-Record. Allerdings
>> brauche schon die richtigen Objekte, da sonst das Paginate-
>> Widget nicht mehr funktioniert.
>>
>> Gruß Michael
>>
>> _______________________________________________
>> TYPO3-german mailing list TYPO3-german at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german