Reprise du message précédent :
c koi cette merise ?

 
une methode de conception d'application : http://www.commentcamarche.net/merise/concintro.php3

Updated

Pendant qu'on parle merise ...
 
en gros, le MCD de mon forum  
 

merci THE REAL SMILEY
PS : pr ton MCD:
Tu vérifie comment qu'un membre a déjà voté ? aucune table pr lister les votant?

THE REAL SMILEY, on peu facilement tromper la protec de ton forum, demande d'afficher la categorie privé, il refuse.
Demande d'afficher le dernier message dans cette categorie, il refuse, demande d'afficher ce mème dernier message mais en changeant l'id de la categorie, et en gardant donc l'id du message et là sa marche...

héhé je te met au défi de casser cette protection de forums restreint sur mon forum (seul moyen que je trouve les bugs, testez lol)
 
en attendant, bonne nouvelle, j'ai viré ma p*tain de requete qui passe en boucle pr recup le dernier topic
j'ai simpleemnt ajouté ds la table des forums l'id du dernier sujet, et de la je recup la date et le membre correspondant
youpi chui passé de 28 à 11 requetes ! powaaa pi c plus rapide a l'affichage

oui, je sais au courant, ça doit faire + de 6 mois que j'ai pas touché une ligne de code dessus, plus de motiv et de temps

 
La table est une meilleure solution pour de diverses raisons. Premièrement, les cookies sont sévèrement limités, tout du moins en théorie (cela dépend de l'implémentation du navigateur):
- pas plus de 4Ko de cookies pour une requête
- pas plus de 20 cookies pour un site donné
- pas plus de 300 cookies au total
 
Ensuite, il sera souvent plus performant de faire une requête sql avec une jointure sur la table des dates de visites que de parser les cookies à chaque requête http et de faire les comparaisons en mémoire.
 
Pour finir, si l'utilisateur se connecte depuis plusieurs ordinateurs (exemple type: maison+boulot), il aura des résultats cohérents avec une table mais pas avec les cookies.
 
Petit détail: pour des raisons d'optimisation au niveau du cache du sgbd, il vaut mieux utiliser une table à part pour ce faire. D'une manière générale, les "bons" sgbd cachent les résultats des requêtes sql dans un buffer et effacent les résultats d'une requête donnée si une table utilisée par celle-ci est modifiée. C'est pourquoi il est préférable de séparer les données changeant fréquemment des données quasi-statiques.

bon à savoir ça
 
comment vous avez procédé au niveau moteur de recherche? je me suis pas encore penché sur le problème

 
tres pratique pour le suivit de drapo  

 
J'y réfléchit encore. Pour l'instant, c'est fait avec des like pour les titres ou les messages et par index (plus ou moins ) pour les auteurs et les dates. Après, c'est géré dans le code du template qui reçoit le post. Grosso merdo, son code ressemble à ça (c'est un exemple "bidon" ):
 

 
 
Ce qu'il faut que je fasse quand j'aurai le temps:
- une limitation du nombre de résultats affichés avec une bufferisation quelque part pour pouvoir ensuite naviguer sur plusieurs pages sans avoir à effectuer la recherche à chaque changement de page
- plus d'options dans le runtime pour ne chercher soit que dans les titres, soit que dans les messages, soit dans les titres et les messages, soit que dans les topics, soit que dans les réponses, soit dans les topics+réponses, ...
- un mode sans like avec quelque chose comme un index
- une date max en plus de la date min
- un parser "mode avancé" avec mots-clés et wildcards (AND, OR, NOT, *, ...)

bon bah dans ce cas je stockerais ca en table par la suite, mais je pense faire comme je pense, stocker l'équivalent du cookie dans un champ de la table des membres

c dommage THE REAL SMILEY, vraiment dommage...
 
 
 
Tu bosses sur koi alors maintenant ?

mon forum amrchant avec des cookies, j'avais pas mal de problème avec des membres qui arrivait pas à ce logguer.
J'ai créer donc un système pour que lorsque on ce log, je rentre dans une table sa:
son mot de passe qu'il doit remettre ainsi que son login.
Rajoute à sa, son IP.
Ensuite je fais un select from mytable where ip="$ip_appelant".
Sa semble bien marcher... Vous en dite koi ?

J'en dis rien, moi j'ai choisi d'utiliser les sessions PHP pour ça  
 
Par contre ça marchera pas dans le cas où plusieurs de tes visiteurs ont une connection derrière un routeur.

Hop, et une nouvelle mise à jour de mon forum. The link http://gfreeman.no-ip.com/FGFasp_NET/Default.aspx .
 
Pour voir la tronche de l'éditeur de texte : http://gfreeman.no-ip.com/FGFasp_N [...] sj=99&mp=6
 
pour voir la tronche d'un topic bien avancé
http://gfreeman.no-ip.com/FGFasp_N [...] 1498&mp=46
 
the real smiley >> tu peux mettre à jour le lien au début de ton post please et le remplacer par celui-ci : http://gfreeman.no-ip.com/FGFasp_NET/Default.aspx
 
Merci
 
Si c'est relativement lent, c'est normal, vous êtes sur une ligne à 128 Ko  

Gfreeman->semblerait que t'ai pas géré les quotes imbriquées
pour ce qui est du javascript pour voir la mise en forme du message quasi en live c'est pas mal mais ca revient au meme de faire un bouton submit ajoutant une prévisualisation du message le tout sans javascript(j'aime autant l'utiliser le moins possible)

 
Spike >> Effectivement, ce n'est pas encore géré. Disons que pour le moment, je m'occupe plus de développer les grands axes pour ensuite faire dans le détails . Mais tu as raison . Sinon concernant le bouton submit, le serveur n'intervient pas du tout dans ma prévisualisation. C'est uniquement la partie cliente qui bosse. Donc ça évite au serveur de devoir ramer pour un travail qui peut être fait par l'utilisateur. Si tu regardes bien, le forum complet est au format JS (le moteur est du JS), c'est un choix !. Par exemple, pour la transformation des smileys ou autres codes UBB, selon le navigateur utilisé, c'est soit le poste client qui bosse, soit le serveur.

d'un autre coté effectuer une prévisualisation coté serveur n'implique pas de requete supplémentaire mis à part l'autentification du membre qui prends quelques ms

par rapport à ca j'avais lancé une discussion avec les devs de MySQL :
 
Si t'as une table quasi statique (et donc dans le cache) et une autre qui bouge souvent, est-ce que si tu peux faire une jointure, il faut mieux la faire (auquel cas le cache ne pourra pas être utilisé à cause de la table dynamique dans la jointure), ou faire un boucle avec la requète sur la table quasi statique effectuée plusieurs fois (mais dont le resultat provient du cache)

 
Oui, en théorie, quelques milli-secondes ne sont rien, mais lorsque tu vois ce temps augmenter avec le nombre d'utilisateurs, tu comprends vite l'intêret de déleguer au maximum. Enfin c'est mon avis   .

je pense que le forum de joce est capable de gérer bien plus de membres simultanées que nos forums persos alors qu'il n'y a pas de moteur javascript pr gérer l'affichage des pages    
 

Euhhhh
 
Faut pas confondre nos différents serveurs respectifs avec la grosse brute de serveur de ce forum, hein.

ce qui engros veux dire que pr estimer correctement le rapport posts/membres/vitesse faut mettre tt les forums sur une meme becane

je bosse à mon taf, ça me suffit amplement

 
Joce a fait un très bon forum, néanmoins, il est loin d'être parfait. Maintenant, et les tests que j'ai pu faire le prouve, déleguer un boulôt grâce au JS couplé à une bonne gestion de cache améliore de beaucoup la santé d'un serveur et d'une bdd. Libre à toi de me croire.... ou non  

tootafé d'accord, perso, le php me sert qu'à faire des requetes, et le JS traite tout ce qui concerne l'affichage (dans la liste des topics et posts, pas dans la liste des forums), y'a qu'à voir le code source

PHP me sert à faire le lien entre la bdd et traite tout.
Je me sers du javascript uniquement pour les formulaires de post.
Et perso je pense que avec un peu plus de temps, le mème serveur qui héberge ce forum, moi aussi je pourrait avoir de bonne stats avec un nombre de connection trés élevés.
 
THE REAL SMILEY > me fait pas croire sa

Ou des bécannes équuivalentes en configuration matérielle et logicielle (sauf les forums en ASP bien sur).

je me demande si les moteurs de recherche arrive facilement a lire dans du js
Parce que bon, pour un forum, ya pas que les capacité qui compte, ya aussi la sécurité, compatiblité,etc

Il faut une version sans cache Js. C'est à mon avis pour cette raison que Joce a laissé tomber le cache Javascript d'ailleurs (double dev).

google est bien capable d'indexer un site ne flash donc un site en javascript ne devrait pas trop lui posser de problèmes...

il va l'indexer, mais est ce qu'il va prendre en compte les mots dans le javascript pour les recherches et pour la pertinence de la pages ?
Et puis faut aussi penser aux autres moteurs de recherche qui n'ont pas une technologie aussi avancé que google.
et puis ya aussi les gens qui ne veulent pas activer leurs javascript, ou qui ne peuvent pas (cyber-café, boulot, etc ...)

Les optimisations en javascript c'est du pipi de chat. Le gros du boulot est effectué coté sgbd donc pas de javascript.

A ce point là ?
Au lieu de faire quelques traitements en PHP, on le passe en JS, ca ne sert à rien ?
 
Sur plusieurs centaines de connections simultanées, je pense que ca a son utilité quand meme  

 
Et la bande passante  

J'ai aucun traitement en javascript et je vois vraiment pas ce que son utilisation pourrait changer.
vous vous servez du javascript pour quoi?
les regex? c'est tout?

tu changes quoi avec ta bande passante?
Avec le mod_gzip d'installé mes pages doivent peser 5ko donc je vois vraiment pas le gain

 
Beh au niveau du traitement des flags, je pense en particulier (Pour moi)
 
En PHP, au lieu de faire un (Exemple bidon) :  if ( drapal > nvlle réponse) { }
 
Beh je le fais en JS, comme ca, c'est traité du côté client ...
 
Je m'a gourré ?

les feuilles de styles sont faites pour cela.