Reprise du message précédent :

http://docs.djangoproject.com/en/dev/topics/signals/

Pour n'importe quel opération sur laquelle quelqu'un d'autre voudrait se hooker, ça correspond à des triggers sql et ça permet d'implémenter facilement des réactions à des actions émises par une section complètement différente du code, en gardant la dite section sans aucune connaissance de ce que tu fais.

Si je comprends bien, tu préfèrerais faire ça :

class Model {
  function AddUser(...) {
    //some code here
    controller::getInstance()->userAdded();
  }
}
 
class Controller {
  function foo(...) {
    Model::AddUser(...);
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

 
plutôt que de simplement faire ça :

class Model {
  function AddUser(...) {
    //some code here
    return bUserAdded ? true : false;
  }
}
 
class Controller {
  function foo(...) {
    if (Model::AddUser(...)) {
      this->userAdded();
    } else {
      //
    }
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

 
 ??
 
Edit : après le post de Masklinn : j'avais pas pensé à ça.

class Model {
  function AddUser(...) {
    //some code here
    controller::getInstance()->userAdded();
  }
}
 
class Controller {
  function foo(...) {
    Model::AddUser(...);
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

class Model {
  function AddUser(...) {
    //some code here
    return bUserAdded ? true : false;
  }
}
 
class Controller {
  function foo(...) {
    if (Model::AddUser(...)) {
      this->userAdded();
    } else {
      //
    }
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

Bah je présume que le modèle aurait pas à implémenter le signal à la mano, il y aurait un truc générique dans Model, comme dans django. Et le hook se fait en dehors, pas dans un contrôlleur.

Stune idée intéressante en fait !
Par contre, comment s'implémenterait le hook ?
 
Par exemple : création d'un user. Le controller demande la création du user. Le user est crée, on renvoie "OK" au controller. Et en même temps, on a généré un event "user created".
 
Imaginons maintenant qu'on est une classe particulière qui souhaiterait consommer l'event : comment on fait ? On passe par une classe plus ou moins virtuelle "UserHook" ?

class Model {
  function AddUser(...) {
    //some code here
    controller::getInstance()->userAdded();
  }
}
 
class Controller {
  function foo(...) {
    Model::AddUser(...);
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

class Model {
  function AddUser(...) {
    //some code here
    return bUserAdded ? true : false;
  }
}
 
class Controller {
  function foo(...) {
    if (Model::AddUser(...)) {
      this->userAdded();
    } else {
      //
    }
  }
 
  function userAdded() {
    //some stuff here
  }
 
}

 
C'est ce à quoi je pensais, pour faire ça, l'utilisation classique du MVC c'est de renvoyer l'infos. De toutes façons, en Web il n'y a pas de méthodes asynchrones, ni de multiples thread en parallèle pour une même requête.
 
Autant les signaux en Qt sur une application lourd ont un sens, autant là je me demande si c'est un bien de vouloir implémenter un système relativement complexe et lourd si on a pas un cas d'utilisation qui le nécessite.

En PHP 5.3 j'aurai imaginer un truc comme ça :
 

 
(super schematiser)
 
Mais bon, faut bien tout prevoir à l'avance quoi. Mais effectivement ça peut permettre d'automatiser à mort tout ce qui est notification dans la GUI. (à la Rails)

Ok.

Bah un peu comme dans django,
 

listen_signal($signal_name, $callback[, $sender])

Si je le fais, c'est qu'a priori je pense que ça le nécessite
En l'occurence c'est pour un module d'inscription a des listes de mailing que je veux externaliser au max.

Ca m'évite de :
- écrire le même code d'inscription au mailing a x endroits (les x endroits où on ajoute un client, les x manières de valider une commande)
- coupler le module de mailing à l'appli

 
 
Enfin une remarque pleine de bon sens !
Quand je vois des frameworks "populaires" (style Symfony) qui tentent de se substituer à Apache, tout en faisant moins bien...    

C'est un moyen de faire abstraction du serveur

Hein ?

Bonsoir.
 
Je me permet de venir vous poser une petite question.
Imaginons la réalisation d'un blog sous symfony par exemple, l'affichage est géré par les vues.
 
Cependant ceci n'est pas très adapté si l'on souhaite réaliser facilement des thèmes pour la mise en forme de nos informations.
 
Quelle est donc la meilleure solution pour faire ceci?
 
Réaliser une petite api qui permet de récupérer les informations les plus importantes et de ce fait pouvoir les afficher dans une page de thème?
 
Merci par avance pour vos suggestions.

tu peux préciser? Je ne comprends pas le problème...?

 
Je vais préciser, si j'utilise symfony par exemple on a une vues associée à un controller.
Si je fais une petite application de blog, j'aimerais ne pas gérer l'affichage des informations dans les vues associés.
 
J'aimerai par exemple pouvoir créer un répertoire thème avec dedans plusieurs fichiers qui pourraient être header.php, index.php, sidebar.php ......
Dans ces fichiers faire ce genre de choses
 

 
Au moins quand je dois modifier la mise en forme, je sais ou faire les modification et non aller chaque fois faire les modifications dans les vues, j'espère avoir était plus clair.
 
Merci

Je connais pas symfony, mais n'importe-quel framework devrait te permettre d'appeler des bouts de vue de ce style dans la vue associée à/appelée par un contrôleur...

tu as le choix entre les vues, les partials et les slots
et tout ça sera dans ton répertoire template par défaut, mais tu peux customiser un peut ton action.class.php pour prendre des template ailleurs ( genre template/theme1/indexsucces.php )

Merci à skeye et flo850, j'ai bien saisi le truc now.
 
Merci à vous deux.

C'est normal de faire les verifs de données dans le modèle ?

A mon sens oui, c'est un peu la couche métier qui est garante de la cohérence des données.

C'est pas au controller de faire ce genre de vérification normalement  

C'est pas au contrôleur de savoir si dans ton modèle il faut avoir pris l'option Jante Alu pour prendre l'option Peinture Métalissé. Car ça c'est un règle métier.
Et ce que tu veux en pratique c'est que si un règle métier change, tu ne la change que dans le modèle et pas dans les n-vue/contrôleur qui pourrais se servir du modèle.

hello,
 
Je me demandais: Lorsqu'on fait des jointures, comment ça se passe pour respecter le MVC?
On fait ça au niveau du contrôleur, ou on fait la jointure dans l'une des tables concernées ?  

jamais de requete au niveau du controleur/vue, tout dans un modèle

Ca se passe dans les modèles.

Ok, c'est bien ce que je pensais.
 
Merci

En principe si tu fait des jointures c'est soit :
- que tu comptes récupérer les données de deux objets en une seule requete.
Exemple un objet Commande contient un objet Client.
- qu'il y a de l'héritage => là t'aura un classe Voiture de sport qui saura qu'il faut qu'elle tape dans la table "Voiture base" + "Voiture sport" lors des requêtes.
 
Dans tout les cas c'est au niveau du modèle que soit tu interpréteras de fait la jointure ou que tu appelleras un 2e modèle.

Oui je sais que c'est dans le modèle que ça se passe.
En fait je n'étais pas certain que se soit correcte d'appeler un modèle dans un autre en respectant le MVC.
 
Je pensais que, puisque tout doit être séparé, on récupère depuis le contrôleur le contenu de Commande, que l'on renvoi vers le modèle client pour récupérer les commandes des clients.
 
Bon après, je sais très bien que sortir toutes les commandes pour récupérer que celle d'un client c'est n'importe quoi.

Tu peux voir l'ensemble de tes modèles comme un package "Modèle". Tu peux donner à ce package toutes les interfaces publiques que tu veux, et ce qui se passe en interne ne concerne que lui. Il n'y a aucune contrainte particulière, à part conserver intactes les interfaces publiques existantes.

Ok, j'ai compris
 
Merci pour ces explications

Bah disons qu'en gros tant que les requêtes restent dans la couche modèle, tu respectes le MVC. Mais ça n'empêche pas que ce soit le bordel au sein même de ta couche modèle, c'est à toi de bien organiser

Perso j'utilise un ORM (Doctrine), ça fait déja une bonne base pour découpler les modèles entre eux.

J'utilise zend framework, je sais qu'on peut le coupler avec Doctrine. Il y a un gros avantage? Quelque soit le projet( petit / gros )?

Si le projet est petit (3-4 modèles/tables) et destiné à le rester tu peux te permettre de pas avoir une organisation béton donc tu peux t'en passer...

Sinon oui ça a plein d'avantages énormes (organisation, découplage, vitesse de codage, souplesse, fonctionnalités genre arbres, multilangues...), par contre comme tout "framework", la doc est bonne mais pas parfaite etc, c'est un investissement.

 
Et au niveau des perfs, le fait de passer par un orm ne les plombe pas ?

un peu ( le premier chargement du modèle peut etre lourd ) , mais ça reste assez raisonnable

Si tu n'utilises pas les caches et que tu n'optimises pas, si. Sinon, si tu utilises les caches et que tu optimises dans les règles de l'art, non, ça peut même être beaucoup plus rapide en cas de grosses requêtes (grâce au cache).

Mais c'est ça qui est pratique : tu peux avoir très vite un résultat fonctionnel (mais un peu plus lent), et optimiser après.

C'est sans compter sur les requetes de metadata useless que les ORM font et qui dans certains cas peuvent être horrible niveau perfs. (donc après faut aussi un DBA qui maitrise son taf).
 
Pour Doctrine de toutes façons à priori pas de gestion correcte des jointure avant la version 2.0.
 
Et pour la vitesse de dev'. Perso j'ai fait un mini-ORM idéal pour mon projet, et en gros j'ai 3 lignes à écrire pour avoir la couche de persistance opérationnelle. Donc toujours savoir si un lib' est vraiment utile ou pas.

Un exemple ? Pour Doctrine je vois pas.

Euh Doctrine 1 qui gère pas bien les jointures ? De quoi tu parles ?

Trop fort, que 3 lignes pour activer le truc Mais je vois pas ce que ça dit sur la vitesse de dev au quotidien...

Sauf si c'est un ORM qui n'en est pas un, une fois l'ORM "config" pour la classe ne question (que ce soit via un INI, un XML ou des propriétés de la classe, etc.), l'utilisation est souvent identique :
- des méthodes d'instances simple pour le Create/Update/Remove/Delete.
- des méthodes de classes permettant de "requêter". (JDOQL/HQL & co quoi en gros...)
 
Après quelque soit l'ORM, sauf dans des situations complexes et rares, ça change pas fondamentalement grand chose niveau code à écrire.
 
Pour en revenir à Doctrine, si t'as une classe UNIQUE qui provient de PLUSIEURS tables via une requête (cas des héritages de classes), ça ne fonctionne pas. C'est pourtant ce qui doit être fait lorsque l'on suit la méthodologie MERISE lorsque l'on réalise le MPD. Doctrine ne sait mapper le contenu d'un objet que s'il provient d'une unique table. D'où l'attente forte pour Doctrine 2.x.

C'est un peu le problème que j'ai vu dans la plupart des couches d'abstration DB - dès que que le mapping DB/classes n'est pas direct c'est le merdier...
Si c'est un "nouveau projet" et que ton ORM te permet de générer la base de données pas de gros problèmes, tu décris ton truc à fond via la syntaxe de l'ORM et basta, mais si tu pars d'une base existante tu te retrouves à devoir re-décrire explicitement un paquet de trucs pour que ta couche d'abstraction ne fasse pas de la merde...