Reprise du message précédent :
Oui, c'est bien les #titre #contenu ...
Pour le remplissage des zones du template, je n'utilise pas directement de "$template->add" mais c'est par ce que j'ai rajouté une couche d'abstraction entre les vues et le template et que j'ai organisé mon gestionnaire de template un peu différement. Mais dans le principe, c'est ça.
 
Evidement, si tu veux créer un systéme de ce genre, il te faudra y réfléchir sufisament en pensant à ce que t'auras besoin pour ton site : si on a besoin d'énormément de souplesse dans l'affichage, ca devient complexe à faire mais si on a pas besoin de beaucoup de souplesse, on peut y arriver sans trop de difficulté. En plus, en fonction des besoins de ton site, le gestionnaire de template proposera d'avantage de fonctions aux autres objets ou au contraire, il en limitera le nombre.

Je viens de lire ça :
http://www.symfony-project.com/boo [...] View-Layer
Et ton système s'en rapproche pas mal j'ai l'impression ^^
Genre un template global avec des "slots", et dans ces "slots", on met des templates
Les templates peuvent contenir des "partials", ce qui finit le tout.
 
Je n'ai pas besoin de beaucoup de souplesse en fait, et je n'ai pas trop envie d'écrire une classe pour ça. Finalement ça ne sera pas MVC, mais on en a pas forcément besoin pour notre projet en fait. Ca le compliquerait trop
 
Merci beaucoup à toi quand même !

Ruby aussi fait ça, c'est à mon sens assez pratique.

perso je dis : MVC => faut pas se faire chier, un symfony et zoo
 
je suis entrain de découvrir la bête et je dois avouer que je suis assez impressionné, sachant que je suis partis à la base pour faire un blog en MVC ben je dois dire qu'avec symfony, tout pleins de problemes feront partie du passé
 
pour l'instant je lis le book, j'en suis au chapitre 8, quand je l'aurais fini, vous verrez mon blog version symfony, certes je n'aurai pas tout le mérite d'avoir construit une application en MVC, mais n'oublions pas que que nous sommes dans un monde où savoir utiliser l'existant est primordial
 
donc moi je dis, avant de programmer en MVC, il faut installer Symfony (je rigole )

Moi je dis que tous ceux que j'ai essayé m'on pris la tête et que j'ai dev un petit truc maison pour le moment, mais que quand j'aurai plus de temps je me vais me dev un petit gestionnaire mvc un peu mieux

symfony pour un blog ? overkill...
un truc comme cakephp ou mieux codeigniter sera bien mieux adapté à ces besoins

Pour utiliser CakePhp sur un de mes projets, je dois dire que je le trouve pas exceptionnel... Peut être pas encore assez mûr, je sais pas trop, mais je regrette d'être parti sur ce framework.

 
si tu reviens une ou deux pages en arrière tu verras que je me suis lancé dans la prog d'un blog en MVC (une sorte d'entrainement) j'ai présenté ce que j'avais fait ici, et ça avait l'air bon (a part l'abstraction de l'sql ) et là j'essaye de faire la meme chose avec symfony, donc toujours dans le chapitre entrainement hein
 
et je pense que le blog est un bon exemple pour s'entrainer.
 
donc voilà, si j'avais besoin d'un blog, y'en a à la pelle, je n'irais pas en programmer un

Bonjour,
 
Petite question qui me turlupine. Comment gérez-vous la base de données. Faites-vous une classe DBCommon et toutes vos classes hérites de celle-ci ?
 
Ou bien elle indépendante et vous faites appelle à celle-ci quand c'est nécessaire ?
 
Comment gérez-vous la connexion :
Vous créez une connexion dès le départ et vous faites vos requêtes puis vous fermez la connexion à la fin du traitement de la page ? Ou bien est-ce que vous créez une connexion à chaque fois que vous ayez besoin d'exécuter une requête SQL ?
 
Merci de m'éclairez sur tout ca car c'est un peu flou.

Je ne créé pas la connexion dès le départ, mais j'instancie la classe en lui passant les params de connexion.
 
Ensuite j'ai juste à faire une requête, ça détecte automatiquement si une connexion existe ou pas. Si c'est le cas, il utilise la connexion existante, sinon il la créé et l'utilise ensuite.

Tu fais ça en appelant la fonction constructeur?

    Pour ma part, j'ai une classe qui s'occupe de la connexion à la BD avec une méthode connexion(). Ma classe hérite de la classe BD elle peut donc utiliser la méthode connexion de la classe BD... (la connexion est donc créée si on en a besoin tout comme Dj Yell).
    J'utilise une connexion dans chaque page qui nécessite une requete SQL, puis je ferme celle-ci lorsque tout mes appels SQL sont réalisés.
    Il me semble que la meilleure méthode serait d'utiliser un pool de connexion (mais je ne suis pas très au point de ce côté là). Mais cela se fait au niveau du serveur apache et non en langage php... (à confirmer par des personnes ayant pratiqué...).
 
P.S. : Dj Yell ? Yell comme la "rappeuse" ?    

 
Mon constructeur se charge uniquement de stocker les paramètres de connexion.
 
En gros j'ai quelque chose de ce genre là (je passe sur la sécurité, et la gestion des erreurs) :
 

function __construct($host, $user, $pass, $base){
    $this->_host = $host;
    etc...
}
 
function query($query){
    if($this->_connect()){
        // On effectue le bazar
    }
}
 
function _connect(){
    if(!$this->_connection) {
        // on effectue la connexion, si ok return true, sinon false
    } else {
        return true;
    }
}

Merci à Dj Yell et C4O2 pour votre aide. Si quelqu'un pouvait me détailler la version de C4O2 avec le pool, ca serait le top

Je sais pas ce qu'il entend par "pool" (un singleton peut être ?)

Presque. Sauf qu'au lieu d'une seule instance tu en autorises N. Après le jeu c'est de savoir laquelle tu refiles quand on t'en demande une...

Ca à l'air compliqué!

    Un cas simple : P1 a besoin de faire une/des requête/S, P1 se connecte je fais ma/mes requête/s, P1 se déconnecte.
    Un autre cas simple : 1er cas P1 fait ce qu'il a à faire et maintenant P2 veut faire une requête. Il se connecte fait ses requêtes et se déconnecte.
 
    Pas de soucis. Ah si un... la connexion à la BDD est la commande qui met le plus de temps à s'exécuter (tout est relatif...). Une amélioration est donc d'utiliser un pool de connexion. Il s'agit d'ouvrir X connections (10 par exemple dès le début), et de maintenir ouvertes. Ainsi lorsque l'on a besoin d'un accès  à la BDD, on ne se connecte pas, mais on récupère une connexion du pool. Et une fois les requetes effectruées, on ne referme pas la connection, mais on la replace dans le pool.
 
    Voici le fonctionnement d'un pool de connexion. Les subtilités mises à part.

pas des masses...C'est un singleton qui stocke N instances de la classe au lieu d'une seule, juste...

 
On fait ça avec les connexion permanentes ? (genre mysql_pconnect) ?

c'est mieux.

 
Oui non je me doute Je voulais juste être sûr d'avoir bien compris?
 
Un forum comme HFR, il fait combien de connexion simultanées en moyenne ?

Pas la moindre idée.
Mais quoi qu'il arrive il a pas intérêt à passer sa vie à ouvrir et fermer les connexions à la base.

Du coup je me pose une question ... quel sont les avantages de la connexion NON permanente ?

Quand une connexion permanente se ferme brutalement (réseau en carafe entre serveur d'applis et de bdd par exemple) il arrive que ça vautre tout jusqu'à redémarrage de l'appli, puisque la connexion est foireuse et qu'on n'en crée pas de nouvelle...(j'ai déjà eu le soucis sur un tomcat).

Et au lieu de stocker N instances, n'est-il pas préférable d'utiliser un compteur ?
 
Auparavant j'avais conçu cette classe :

 
Le problème est que ma connexion est gardé jusqu'à la fin du traitement de la page. J'ai donc une connexion à ma BD qui est monopolisée.

...et il se passe quoi quand tu demandes une connexion la fois suivante, ça explose?

Rien compris à ton truc ...

En fait le truc qu'il faudrait faire, c'est n'ouvrir aucune (ou une seule) connexion.
 
À la première demande, on ouvre, et on ferme pas, à chaque demande on envoi l'instance déjà ouverte. Si jamais une instance est déjà en cours d'utilisation et qu'une autre demande est faite, alors seulement on créé une deuxième connexion... qui restera ouverte.
 
Et ainsi de suite, comme ça le nombre de connexion "suit" la demande (en imposant toutefois une limite )

Beaucoup trop casse-couilles.
Tu stockes un pool de N connexions, et le numéro de la dernière fournie. A chaque demande tu passes au numéro suivant, et à la fin tu boucles. Et tu fais l'initialisation quand t'en as besoin la première fois.

 
Oué, c'est con ce que je dis, les connexions étant permanente on va forcément arriver à un moment ou un autre à la "limite", et donc elles seront toutes ouverte, et donc ça revient au même, et donc t'as raison, et donc je suis con, et donc voila

ah non, ta solution est faisable. A condition que le consommateur d'une connexion prévienne quand il la libère.

LoL non du tout.

Voila comment je vois là chose : J'ai besoin d'une connexion, je vérifie qu'il n'en existe pas. S'il n'en existe pas, je crée la connexion. S'il en existe une, je ne fais rien. Ensuite, j'exécute ma/mes requêtes jusqu'à la fin.

Je dois faire un héritage pour que ca fonctionne. Et bien entendu, c'est la raison de mon "premier" post sur ce sujet. A savoir si ce n'est pas mieux de créer une classe DBCommon à part pour pouvoir gérer les connexions au mieux. Et c'est là, que tout devient flou pour moi.

Je ne répondais qu'à la partie "compteur seulement" de ta réponse.
Comment tu veux utiliser et réutiliser plusieurs connexions sans les stocker?

Oui si je n'utilise pas de tableau, c'est sûr ca ne sert à rien. Mais dans ce cas là, je ne vois pas du tout comment gérer la bête.

Bah c'est très simple...ça donnerait un truc du genre (bon attention je me suis amusé, mais c'est p-e blindé de conneries, hein...:D):

require_once('Connexion.class.php');
 
class DbConnexionFactory{
  private $next;
  private $poolSize;
  private $connexionResources;
  private $instance;
 
  private $mesparametresdeconnexionàlabase;
  
  private function __construct($poolSize, $mesparametresdeconnexionàlabase){
    self::$poolSize = $poolSize;
    self::$connexionResources = array();
    self::$next = 0;
 
    self::$mesparametresdeconnexionàlabase = $mesparametresdeconnexionàlabase;
  } 
  
  /*
    Appelée une fois au démarrage du script par la conf ou je ne sais quoi...
    Les appels suivants ne font rien.
  */
  public static function init($poolSize = 1, $mesparametresdeconnexionàlabase){
    if(empty(self::$instance)){
      self::instance = new DbConnexionFactory($poolSize, $mesparametresdeconnexionàlabase);
    }
  }
 
  public static getConnexion(){
    if(!array_key_exists(self::$connexionResources, self::$next)){
      self::$connexionResources[self::$next] = ma_fonction_de_connexion_qui_retourne_une_ressource();
    }
 
    $conn = new Connexion(self::$connexionResources[self::$next]);
 
    if(self::$next == self::$poolSize - 1){
      self::$next = 0;
    }
    else{
      self::$next++;
    }
    
    return $conn;
  }
 
}

A l'utilisation tu initialises ton pool une fois, et ensuite quand tu veux une connexion tu fais un appel à DbConnexionFactory::getConnexion() et tu récupères un objet Connexion prêt à l'emploi...

Avec MySQL le overhead lié à la connexion est faible (comparé à d'autres SGBD) donc on évite le mysql_pconnect et pas besoin de pool de connexion

Avec oracle par contre l'overhead est assez énorme.

require_once('Connexion.class.php');
 
class DbConnexionFactory{
    // ...
}

Ok, ca j'ai compris. Mais ils meurent quand? D'après ce que tu me montre, la connexion est fermée une fois le script fini? Non?

Ben c'est permanent ... pourquoi tu veux les faire mourrer ?

pas si tu utilises une connexion persistante, style mysql_pconnect. Sauf que là je me demande si php est capable de créer plusieurs connexions persistantes avec les mêmes identifiants, en fait...ça doit dépendre des bases de données...