13/09/2011, 10:54:56
ok je vois. J'imagine que tu as moult champs personnalisé ? tu gère combien de champs complémentaire pour les news ?
alors voilà une idée qui vaut ce qu'elle vaut : vu que News à l'air de faire des requêtes en séquentiel : passes toi de News pour le frontal et réalise ta propre requête sql avec des jointures (reprend mon exemple dans les liens que je t'ai filé)
tu connais les champs additionnels, ce sera aisé de réaliser une "super requête" qui irra tout récupérer en une seule requête (et non 1 + 499 supplémentaires sur les tables de champs additionnels). Tu peux également t'aider du mode debug pour observer les requêtes effectuées et la concaténer en une seule encore plus facilement.
une fois ta requête éprouvée sous phpmyadmin, tu fais une balise utilisateur dans laquelle tu fait ta requête en limitant aux 4 premiers résultat. Tu peux également jouer avec les paramètres d'entrée des UDT pour laisser cette limite de 4 être décidée par le paramètre de ton UDT : {monUdt limite=7}
ensuite toujours dans ton UDT tu créés un objet standard php qui contiendra ce que tu as remonté depuis la requête SQL :
tu boucles afin d'ajouter successivement cet objet dans un array que tu repousses au final dans smarty
tu ajoutes cet UDT en début de ton gabarit (genre avant le premier appel de {News}
tu supprimes de ton gabarit le premier appel de News : {news summarytemplate='mon_gabarit_a_appeler_une_seule_fois' number='4'}
et hop normalement les autres appels récupèreront ta super liste et l'utiliseront dans leur propre gabarit
Alors attention : la structure de ton objet doit être équivalent aux objets utilisés dans le gabarit, ça sera pas une partie de plaisir. Mais c'est certain ce sera plus performant.
J'ai déjà eu à faire face à ce genre de problème : la généricité absolue entraine bien trop souvent des soucis de performance. J'ai personnellement contourné le problème en gérant un mini cache interne dans mon module. Avant d'aller refaire une requête déjà effectuée, il pioche directement le résultat dans le cache. Ce n'est évidement pas parfait (quid d'une mise à jour de la donnée entre deux requêtes ?) mais les perf ont monté en flèche avec ce genre d'astuce.
alors voilà une idée qui vaut ce qu'elle vaut : vu que News à l'air de faire des requêtes en séquentiel : passes toi de News pour le frontal et réalise ta propre requête sql avec des jointures (reprend mon exemple dans les liens que je t'ai filé)
tu connais les champs additionnels, ce sera aisé de réaliser une "super requête" qui irra tout récupérer en une seule requête (et non 1 + 499 supplémentaires sur les tables de champs additionnels). Tu peux également t'aider du mode debug pour observer les requêtes effectuées et la concaténer en une seule encore plus facilement.
une fois ta requête éprouvée sous phpmyadmin, tu fais une balise utilisateur dans laquelle tu fait ta requête en limitant aux 4 premiers résultat. Tu peux également jouer avec les paramètres d'entrée des UDT pour laisser cette limite de 4 être décidée par le paramètre de ton UDT : {monUdt limite=7}
ensuite toujours dans ton UDT tu créés un objet standard php qui contiendra ce que tu as remonté depuis la requête SQL :
Code :
$toto = new stdclass();
$toto->date = ...
$toto->titre=
...
$toto->champsAdditionnel = ...tu boucles afin d'ajouter successivement cet objet dans un array que tu repousses au final dans smarty
Code :
$smarty->assign('itemsNews', $la_super_liste);tu ajoutes cet UDT en début de ton gabarit (genre avant le premier appel de {News}
tu supprimes de ton gabarit le premier appel de News : {news summarytemplate='mon_gabarit_a_appeler_une_seule_fois' number='4'}
et hop normalement les autres appels récupèreront ta super liste et l'utiliseront dans leur propre gabarit
Alors attention : la structure de ton objet doit être équivalent aux objets utilisés dans le gabarit, ça sera pas une partie de plaisir. Mais c'est certain ce sera plus performant.
J'ai déjà eu à faire face à ce genre de problème : la généricité absolue entraine bien trop souvent des soucis de performance. J'ai personnellement contourné le problème en gérant un mini cache interne dans mon module. Avant d'aller refaire une requête déjà effectuée, il pioche directement le résultat dans le cache. Ce n'est évidement pas parfait (quid d'une mise à jour de la donnée entre deux requêtes ?) mais les perf ont monté en flèche avec ce genre d'astuce.