Reprise du message précédent :

 
Tu préfères te faire un truc pourri pour tes templates avec des includes, plus des rewrites d'URL à la main qui seront pas en concordance avec le reste du site, plus un fichier de config à l'arrache pour ta bdd, plus un autre fichier de config si tu dois faire un formulaire de contact, etc etc ?
Bah moi non

 
O la comparaison qui n'a rien à voir.
 

 
Moi si

Désolé d'intervenir pendant votre débat, mais j'ai une question smarty (pas de commentaire merci) et j'ai un problème :
J'ai décidé d'étendre ma gestion du cache au sommaire qui est dynamique. Sauf que je ne pourrais pas le faire avec la structure actuelle des templates (include ne permet pas d'utiliser is_cached par exemple). Donc je pense ne plus utiliser d'include, mais de faire plusieurs appels de display(), qui me permettra d'utiliser is_cached et compagnie pour mettre en cache mon menu.
Ca donnerait, dans mon PHP :

$template->display('top.tpl');
$template->display('sidebar1.tpl');
$template->display('sidebar2.tpl');
$template->display('main.tpl', $id);
$template->display('footer.tpl');

Au lieu d'avoir çà dans le template :

{include file='top.tpl'}
{include file='sidebar1.tpl'}
{include file='sidebar2.tpl'}
(main)
{include file='footer.tpl'}

Donc ma question est : multiples appels à display() dans le php ou suite d'include smarty dans le template ?
Mais bon je ne sais pas si tous ces diplay auront un impact au niveau des perfs, ou si c'est une solution un peu crade (vous allez me dire rien qu'utiliser smarty est un peu crade en soi).
Seulement, je ne vois que çà pour résoudre mon problème de cache
Merci.

 
J'ai utilisé code igniter récemment pour un site qui a moins de pages que ça et - tiens-toi bien - pas de base de données
J'avais pas touché à PHP depuis longtemps, je connaissais pas le framework (donc double pénalité) et pourtant j'ai pu sortir un truc en un temps assez rapide. Et qui fonctionne. Et que je peux étendre à l'envi très facilement.
 
Que demande le peuple ?

je test code igniter tiens

Je pencherais pour plusieurs display
Sinon y'a la balise insert à la place d'include qui je crois ne regarde pas le cache

niveau perf je sais pas, faut bencher pour voir la différence, y'en a pas pour bien longtemps, mais je pense pas qu'il y ai vraiment de grosse différences

Ca permet de pas servir tes images via ton domaine standard
Ca permet de servir certaines images via un nom de domaine sans cookies
Ca permet de réutiliser ton même code sur d'autre projets qui sont sur d'autres URLs

Et c'est déjà pas mal

je rajouterais que ça permet aussi de faire tourner une appli dans un sous dossier, mais bon c'est comme si c'était un autre domaine

Le contenu de ce message a été effacé par son auteur

ok merci

Le contenu de ce message a été effacé par son auteur

Le contenu de ce message a été effacé par son auteur

Sauf que ça c'est hautement improbable. Devoir un jour passer un site de dev vers prod, ça l'est un peu moins

D'autres sources

Je tiens à dire que les masterpage c'est bien
Dommage que je ne connaissait pas leur existence il y a un an

Pour les deux premiers, l'appli sur laquelle on bosse utilise ça :
HTML : club.doctissimo.fr
Images qu'on veut référencer : images.doctissimo.fr (+ même domaine donc bien pour le ref)
Images qu'on veut pas référencer & CSS & JS : imdoc.fr (+ pas de cookies)
 
Et quand on sert des images, pas beosin de sortir un apache qui bouffe plein de mo pour chaque process comme le faisait remarquer quelqu'un d'autre plus haut, le contenu static on le sert via d'autres serveurs, donc forcément un autre sousdomaine.
Donc la question de faire un chemin relatif ne se pose même pas en fait, c'est forcément de l'absolu.
Mais après, toutes nos url sont en absolu, pour la 3ieme raison : le code est réutilisable dans un autre contexte sans se casser le cul

 
Ici j'ai l'inverse, le serveur statique light qui reporte les requètes à faire gérer par le dynamique, donc je peut tout garder sur le même domaine si je veut.

 
PQ

Excellent, ça bouffe pas trop cette redirection ?
Quels softs / paramétrages ?
Comment tu détectes que c'est une url à traiter dynamiquement et pas en static ?

Et ça te permet d'étendre facilement ça en un load balancer si besoin

Au final c'est moins performant qu'un serveur qui sert de CDN à côté

Jamais eu à tester en vrai conditions difficiles, j'imagine que ça ajoute un peu de latence sur le dynamique mais pas d'idée plus précise que ça.

En front c'est nginx, et la config c'est ça en gros :

La partie dynamique derrière c'est un serveur custom en java, qui voit pas de différence entre une requète direct et une requète par le serveur statique (À condition qu'il supporte correctement les X-Real-IP et X-Forwarded-For).

La raison principale pour faire ça c'est le serveur custom, il sait pas servir de requètes statiques, c'était plus simple de mettre nginx devant que d'ajouter du code dans le serveur custom pour qu'il appelle nginx.

[edit]
Grillaide

Trop de mots trop de siiiiiigles

FOUTAISES !
 

À partir du moment où tu fais du load balancing, il y a des chances assez fortes pour que ton load balancer soit un SPOF

Au pire un micropoil moins performant sur les requêtes dynamiques, si tu rediriges sur ::1.

Après si tu fais du load-balancing ou que tu rediriges les requêtes dynamiques sur une autre machine, oui tu vas évidement introduire un délai plus conséquent (mais pas nécessairement bien impressionnant à l'échelle des délais existants)

http://xanana.ucsc.edu/~wgscott/xt [...] SH_on_OS_X
 
nice...un OS avec un vrai shell, ça va me plaire ça

C'est intéressant comme méthodo en tout cas !
 
Ca me fait penser à un argument pro "multiples domaines" : multiplier les noms de domaines pour paralléliser les téléchargements (généralement recommandé de 2 à 4 domaines différents)
Mais la méthodo comme ça est plus classe je trouve, un même domaine et un service dépendant du média servit.
 
Je me demande l'impact d'une regex supplémentaire pour chaque hits par contre

Là tu sors un peu l'artillerie lourde

Vu la simplicité de la regex, c'est de l'ordre de la microseconde.

 
Je visualise pas tout le truc correctement, mais le switch devient pas un SPOF ?

Et le temps/mémoire "perdu" par la prise en charge de la requête dynamique par le server static (avant de rediriger donc) ?
us ou ms ?

Pour ceux qui utilise CI, comment vous faites pour gérer votre template ?
 
Sur chaque vu vous faites des includes pour le header, le menu le footer, etc ?
 
Parce qu'à la main, j'ai mon design, et là où le contenu change, j'ai une include en fonction de l'url, mais sur ci...

A l'arrache, chaque contrôleur va chercher une vue header et une vue footer. Oui c'est moche, mais pour le coup je ne connais pas la bonne pratique associée.

J'ai trouvé ça.