Forum d'entraide PHPFrance

Bonjour à toutes et à tous,

Voilà, mon projet prend forme, tout les modèles sont presques finient et, je me commence à étudier les contrôleurs déjà fait par mon collègue, ainsi que ses modèles...
Hors, je m'aperçoit que nos deux manières de coder sont différentes, ce qui est normal, mais sans parler du nommage des variables/classes/méthodes, ses méthodes sont plus fournies en conditions que les miennes, je m'explique, moi je me borne à ne faire que majoritairement des requêtes dans mes méthodes, oui, on ne travaille que en objet..., alors que lui va tester les droits, l'existence des arguments, faire la gestion d'erreurs, du cache etc...

Quelle est la bonne méthode à appliquer ? Pourquoi ?

Par avance merci de votre aide...

Hey ,

Si d'entrée de jeu vos conventions de nommage ne correspondent pas, il faut se remettre en question mon p'tit bonhomme. Sinon votre projet sera un beau gros bazar que seuls quelques illuminés (les créateurs ?) pourront comprendre. Et ça, c'est mauvais.

Ensuite, si je devais donner mon avis, faire beaucoup de tests dans la couche modèle a un sens. Cela évite de faire les tests dans le(s) contrôleur(s) qui va (vont) exploiter le(s) modèle(s). Mais après, ça dépend de ce que tu veux faire de ton modèle. Toutefois je préférerais la solution de ton binôme plutôt que la tienne aux vues de l'énoncé.

Enfin, je trouve ta méthodologie un brin bizarre : commencer par les modèles ? Euh, on commence par une phase d'analyse, donc diagrammes Merise, UML et tout le toutime. Ensuite, tu mets en place l'architecture de ton application. Donc tu vas créer les différents modules, constitués des contrôleurs. Et ensuite, oui, tu peux t'attaquer aux modèles (puis ré-attaquer les contrôleurs). Ceci me paraît être une méthodologie plus intéressante et cohérente (mais ça reste discutable).

Si si, tout avis est bon à prendre, personnellement, vu que c'est un projet assez conséquent, on a utiliser le plus de méthode possible, déjà, notre chef de projet, je crois que ça s'appel comme ça, nous a fait un joli Cahier de Charges d'une centaine de page, nous avons mit quelques temps à l'assimilier, toute l'eéquipe de codage, aidé de son auteur, bref, non avons mit en place notre architecture sur le FTP, les conventions d'url (pour l'url-rewriting, la liste des pages, etc), les conventions de nommages des tables modules_(r|t)_table, les conventionsde nommages des clés fk/pk, nous avons distingués la liste des fonctions pour chaque module, nous avons dresser un ordre de conception des modules, bref, après un moi d'organisation, très instructif, au passage, nous nous somme mit à la pratique, après avoir fixé une convention d'écriture, la syntaxe BSD, des commentaires, la PHPDOC, l'organisation des objets, utilisation spécifique de PDO, convention de retour de fonction...
Grosso-modo, après 5 mois et demi de développement, tout les modèles sont pratiquement prêt...

Voilà, donc si je te suis bien, il vaut mieu faire (ébauche grossière) :

function fonction_type($nom, $prénom)
{
   if(!gestion_droits::autorise('inscription'))
   {
      base::erreur('necessite_droit');
      return false;
   }
   if(!isset($nom) || empty($nom))
   {
      base::erreur('nom_manquant');
      return false;
// ...
//requete SQL d'ajout
}

// Contrôleur
fonction_type($_POST['nom'], $_POST['pseudo']);
Base::parse('tpl/ajout_reussit.tpl');

Que :

function fonction_type($nom, $prénom)
{
   //requete SQL d'ajout (avec des protection, etc.)
}

// Contrôleur
   if(!gestion_droits::autorise('inscription'))
   {
      base::erreur('necessite_droit');
      return false;
   }
   if(!isset($_POST['nom']) || empty($_POST['nom']))
   {
      base::erreur('nom_manquant');
      return false;
// ...
// Si tout est bon
fonction_type($_POST['nom'], $_POST['pseudo']);
Base::parse('tpl/ajout_reussit.tpl');

J'avou que je serait plus trop quoi choisir maintenant...

PS : Je caricature un peu dans le second, je placerais peut-être l'existence des variable dans mon modèle

Ça dépend de la nature de tes tests. Si tu testes l'existence de valeurs, autant le faire dans le modèle. Si tu testes la bonne forme des valeurs, autant le faire dans le contrôleur.
Là encore, c'est un exemple. Ça dépend de la nature des tests, des données manipulées, de ce que tu veux en faire etc.

Tu es fasses à un faux problème (que tu t'aies monté tout seul ?). Faire des tests, oui c'est bien, c'est évident …

Au passage, si vous avez travaillé comme des petits fous votre projet, alors pourquoi est-ce que vous n'avez même pas les mêmes conventions de nommage ? D'autant que tu dis que vous avez poussé le vise jusqu'au type de retour de fonction …
Et pas mal de choses que tu as énoncé n'ont aucune sorte d'importance ou sont ridicules. Je pense notamment à l'architecture sur le serveur FTP qui réunit les deux. Premièrement, ça n'a aucune importance car l'architecture de ton application est pareille sur le local que le distant (théoriquement). Le serveur FTP ne permet que le transfert, ça ne correspond à rien. Deuxièmement, c'est ridicule car on ne parle jamais d'architecture FTP, parce que ça ne rentre jamais en compte …

Certes, j'aurais plutôt dûe parler parler d'arborescence des fichiers...
Le problème, c'est que, si j'ai bien compris, c'est au contrôleur d'appeler les vues et non aux modèles...

Voilà où est mon soucis, mais je vais bosser ça ^^

Tu devrais peut être passer par des tutoriels comme celui ci : http://julien-pauli.developpez.com/tuto ... ontroleur/

Et aussi définir des normes pour ce que tu veux faire, par exemple le nommage des variables, des méthodes, des classes etc ...

Comme dis plus haut si vous partez déjà sur 2 méthodes différentes il y a peu de chances que le projet aboutisse, peut être devriez vous reprendre le projet sur papier avant de foncer dans le code.

Se demander que doivent faire les controleurs, les actions sur le modèle, ce que doit faire la vue, avoir des règles que vous respectiez à la règle, choisir un ORM, développez le sien sois même si besoin est etc ...

Il y à une grosse phase de discussion, mise en forme d'un projet, avant de se jeter sur le code je pense et si on s'en tiens à quelque chose d'écrit et que l'on respecte jusqu'à la fin du projet il n'y aura aucune surprise.

Le problème, c'est que, si j'ai bien compris, c'est au contrôleur d'appeler les vues et non aux modèles...

Classiquement, tu as un contrôleur frontal qui se charge du routage, dispatche etc. Ils appellent les contrôleurs d'application qui vont bien. Ensuite, ce sont les contrôleurs d'application qui font le lien entre le modèle et la vue. Ils appellent le modèle, traite les données de sa provenance, et les envoies à la vue. Grosso modo, c'est ce qui se passe.
Tu as après deux familles qui se distinguent : les MVC de type push et pull. Je t'ai décris le pull précédemment. Pour le push, la différence réside majoritairement dans le fait que la vue peut accéder/atteindre à la couche modèle et communiquer avec elle.
Mais de là à dire que c'est bi-directionnel, i.e. que le modèle peut communiquer avec la vue, c'est assez absurde, inutile et est un peu un non-sens en soit …

Tu devrais peut être passer par des tutoriels comme celui ci : http://julien-pauli.developpez.com/tuto ... ontroleur/

Déjà lu, pas plus avancé

Et aussi définir des normes pour ce que tu veux faire, par exemple le nommage des variables, des méthodes, des classes etc ...

Comme dis plus haut si vous partez déjà sur 2 méthodes différentes il y a peu de chances que le projet aboutisse

Désolé de m'énervé un peu, mais je suis pas nouveau venu sur ce forum, donc je me passerais bien volontier de cette remarque...

Se demander que doivent faire les controleurs, les actions sur le modèle, ce que doit faire la vue, avoir des règles que vous respectiez à la règle, choisir un ORM, développez le sien sois même si besoin est etc ...

Certes, les conventions de nommages sont passé à travers, par contre, hors mit ralentir le serveur, je vois pas bien ce que vient faire l'ORM...

Il y à une grosse phase de discussion, mise en forme d'un projet, avant de se jeter sur le code je pense et si on s'en tiens à quelque chose d'écrit et que l'on respecte jusqu'à la fin du projet il n'y aura aucune surprise.

Bah, jusque là on s'est tenu a tout ce qu'on a dit, mais on a pas tout dit...

HyWaN, ça doit être moi, mais, ça me dit toujours pas ce que je dois faire, je vais donc persister dans mon idée :
En tout logique :
* Le modèle effectue des actions "bêtement", et renvoi un résultat
* la vue affiche "bêtement ce que lui envois le contrôleur
* Le contrôleur analyse la requête de l'utilisateur, et appel frénétiquement les modèles et appel la bonne vue en fonction des retours des modèles

Donc, selon moi, la gestion des droits et des erreurs se fait au niveau du contrôleur...

Si je me trompe pas, grogne une fois, euh, mais oui, si non tâche de t'imaginer un jeune dans le monde de la programmation, qui a du mal avec les pavés compacte (qui sont bien écrit, mais un peu accrobatique, a mon gout)

Par avance merci

hors mit

Elle est belle celle-là. En général, je rigole mais je ne dis rien. Là, c'est trop. Ça s'écrit « hormis », c'est un seul mot, si si.

Désolé de m'énervé un peu, mais je suis pas nouveau venu sur ce forum, donc je me passerais bien volontier de cette remarque...

Ça n'a rien à voir avec l'ancienneté sur le forum. J'apprends encore des choses aujourd'hui en lisant le forum (et c'est pour ça que j'y reste en partie).

ça doit être moi, mais, ça me dit toujours pas ce que je dois faire, je vais donc persister dans mon idée

Tu devrais plutôt me dire ce que tu ne comprends pas au lieu de refuser ce que je te dis. Je te rappelle que j'ai commencé mon message par « Classiquement », ce qui signifie « Dans la majorité des cas ». Chaque MVC fonctionne différemment. En revanche, il faut que les trois notions de couches — respectivement le modèle, la vue et le contrôleur — soient fortes, i.e. bien présentes. Il faudrait aussi (ne serait-ce que par mimétisme) s'inspirer du fonctionnement des autres MVC. De cette façon, tu apprendrais, et surtout tu aurais un modèle déjà éprouvé et qui a fait ses preuves.
Ton raisonnement est correct en soit, sauf que tu ne distingues pas contrôleur frontal et contrôleur d'application. Je ne sais pas si c'est volontaire ou que cette notion t'as échappé, à toi de préciser.
Tu me dis aussi que, pour toi, la gestion des droits et des erreurs s'effectuent dans le contrôleur. Oui bien sûr, qui a dit le contraire ? Mais là encore, ça dépend de l'erreur. Si c'est une erreur qui peut se comprendre ou se détecter sur le modèle, alors on évite de le faire dans le contrôleur (car tu accrois tes chances d'avoir un bug dans ton application).

Il faut que tu comprennes qu'une architecture n-tiers (soit MVC couramment) est un ensemble de design patterns. Par conséquent, l'idée et la philosophie est là, mais l'instanciation reste propre à chaque système. Plus trivialement : tu te démerdes pour l'adapter.

Enfin, je dois être aussi vieux que toi, donc ton argument est irrecevable . Aussi je t'accorde le fait que le codage d'un MVC est acrobatique (le terme était bien choisi). Un bon MVC capable de s'adapter à toutes les solutions possibles n'est pas simple à faire (et je sais de quoi je parle je pense), et de bonnes connaissances aussi bien en objet qu'en architecture sont nécessaires. Connaissances que tu peux apprendre .

Si si, je distingue bien les deux types de contrôleurs, là je ne parle pas de contrôleur frontal, mais c'est juste que à force d'écrire, enfin bref...
Si non, je m'aperçoit que je me suis mal exprimmé, je parlais des erreurs du membres, à noté que je ne considère pas une tentative de violation des droits comme une erreur, mais, par exemple le fait d'oublié le titre d'un sujet, etc.
Pour les erreurs d'éxecutions, ça c'est autre chose qui est, je suis d'accord géré dans le modèle
Si non je suis prêt à apprendre, d'ailleur, je ne fais qu'apprendre...

(et c'est pour ça que j'y reste en partie).

Et parce que c'est bon pour le karma

Euh, je ne pensais pas exactement à ça . Les raisons principales sont : j'aime aider, j'apprends et j'arriverai à monter à Paris pour une PHPFranquette un jour .

Et c'est bon pour le karma, CQFD..

hmm.. désolé, je vous laisse reprendre la discussion sur le MVC (qui est devenu un simple Buzzword, je pense).. C'est fou le nombre d'interprétations différentes qu'il doit y avoir concernant le MVC.. l'autre jour je suis tombé sur les premières discussions au sujet du MVC, à l'époque du Xerox parc et du Smalltalk, dans les années 70.. c'était tout autre chose à l'époque.

Edit: ben le voilà tiens: http://heim.ifi.uio.no/~trygver/themes/ ... index.html

Merci a tous, et surtout a HyWaN, à noté que je suis pas sûr que ce MVC soit tout a fait adapté à tout nos site, enfin, je dis ça, je dis rien ^^