lien vers une méthode d'objet

Bonjour,

j'ai un problème de débutant en POO : je voudrais faire un lien vers une méthode d'objet ; j'ai fait :

Code:

---

1 2 3

$ced=new cedric(); ... <a href="ced->add-enreg()">add-enreg</a>

---

et le lien est http://---/ced-%3Eadd-enreg() ; comment faire ?

Salut,

C'est pas possible. Que veux-tu faire exactement ?

C'est plutôt un problème de compréhension du fonctionnement d'un langage serveur.

Le PHP s'exécute côté serveur, quand ta page s'affiche dans le navigateur le script a déjà été exécuté. Pour exécuter de nouveau du PHP il faut un rechargement de la page (ou un appel Ajax).

Edit : Tu peux tenter ta chance en cherchant le fonctionnement client-serveur dans les articles Dvp (pas trouvé mon bonheur) ou bien aller chercher sur ton moteur de recherche préféré.

Cordialement,
xTG.

comme l'a dit transgohan, il fait bien que tu penser au fait que tu ne peut pas executer de php sur un navigateur. Ce que je te conseille, c'est de faire un lien vers une page qui elle apelle la methode. Mais si tu ne veux pas recharger la page, tu peux egalement le faire en AJAX.

J'avais même pas réalisé que mon lien, c'était du PHP !:mrgreen: Je vais suivre ton conseil simcos (et sans ajax, car connais pas).

C'est pas encore au point ; voilà ce que j'ai fait :
fichier principal=depense.php :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<?php // inclusion de la classe include_once("class_cedric.php");   // création d'une instance $ced=new cedric(); ?> ... <ul id="navigation"> <li><a href="add-enreg.php">add-enreg</a></li> ... </ul>

---

add-enreg.php :

Code:

---

1 2 3 4 5

<?php // inclusion de la classe include_once("class_cedric.php"); $ced->add-enreg(); ?>

---

la méthode que je veux appeler (class_cedric.php) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public function add_enreg() { ?> <form action="this->action_add()" method="POST"> <table> <tr><td>Date: </td><td><input name="date" id="datepicker" type="text"></td></tr> <tr><td>Montant : </td><td><input name="montant" type="text"></td></tr> <tr><td>Objet : </td><td><input name="objet" type="text"></td></tr> </form> <?php //formulaire demandant la dépense       }

---

j'ai l'impression de suivre tes conseils simcos, alors pourquoi ça :

Citation:

---

Fatal error: Call to undefined function enreg() in /homepages/18/d246623212/htdocs/cedric/add-enreg.php on line 4

---

(ligne 4 : $ced->add-enreg();)

add-enreg
add_enreg

c'est vrai que ça peut pas le faire, mais avec add-enreg.php :

Code:

---

1 2 3 4 5

<?php // inclusion de la classe include_once("class_cedric.php"); $ced->add_enreg(); ?>

---

on a :

Citation:

---

Fatal error: Call to a member function add_enreg() on a non-object in /homepages/18/d246623212/htdocs/cedric/add-enreg.php on line 4

---

alors que "add_enreg()" est une méthode de la classe "ced" et qu'un objet de cette classe a été créé dans "depenses.php" ($ced=new cedric();)...

C'est parce que ton objet Cedric n'est pas instancié dans ton fichier add-enreg.php.

Code:

---

1 2 3 4 5 6

<?php // inclusion de la classe include_once("class_cedric.php"); $ced = new cedric; $ced->add_enreg(); ?>

---

OK et merci ; maintenant, ça marche, mais l'idée, c'est que la méthode contienne un fomulaire html dont l'action serait une autre méthode de la classe. Voici l'idée ; je sais bien que comme ça, ça ne peut aller (mélange de html et de PHP), mais c'est pour montrer l'idée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?php --- private function action_add() { --- }   public function add_enreg() { ?> <!--formulaire demandant la dépense--> <form action="$this->action_add()" method="POST"> <table> <tr><td>Date: </td><td><input name="date" id="datepicker" type="text"></td></tr> <tr><td>Montant : </td><td><input name="montant" type="text"></td></tr> <tr><td>Objet : </td><td><input name="objet" type="text"></td></tr> <tr><td>&nbsp;</td><td><input type="submit" value="add"></td></tr> </form> <?php }

---

Salut,

Citation:

---

Envoyé par laurentSc

OK et merci ; maintenant, ça marche, mais l'idée, c'est que la méthode contienne un fomulaire html dont l'action serait une autre méthode de la classe.

---

Tu fais fausse route. Ce que tu demandes est un non sens :
quand tu soumets un formulaire : tu utilises une route (url) pour la soumission, cette route doit être analysée, validée et le traitement redirigé vers un contrôleur qui lui doit faire appel aux classes métiers appropriées pour effectuer la tâche.
Dans ton cas, l'appel $this->action_add() ne se résume qu'à la route qu'il faut emprunter pour pouvoir traiter le formulaire avec ses données et en aucun cas le code php qui va faire le traitement.

Il faut revoir ton organisation :

Code:

---

1 2 3 4 5 6 7 8

- Concept : Depense - Actions : nouvelle demande - vérification - demande de modification... - Routes : 1 nouvelle demande : http://www.tonsite.com/depense/new 2 nouvelle demande soumission : http://www.tonsite.com/depense/new/submit... - Controllers : Controller 1 (pour la Route 1) : tu sers la page avec le formulaire adéquate Controller 2 (pour la Route 2) : tu récupères les données et tu les traites Controller 2 appelle le Model : Depense::add(array $p) { } pour créer une nouvelle demande de dépense...

---

C'est schématique mais cette séparation est obligatoire pour t'y retrouver.

Merci de ta réponse :ccool: ; je ne suis pas surpris que tu dises que je faisais fausse route :(, par contre, j'ai du mal à suivre ce que tu proposes ; aurais-tu un exemple (qui n'a rien à voir avec ce que je voudrais faire) pour que je comprenne (je marche beaucoup avec les exemples (et si y a un formulaire html dedans, c'est encore mieux, mais même si y en a pas, ça peut quand même m'aider)).

Citation:

---

Envoyé par laurentSc

j'ai du mal à suivre ce que tu proposes

---

A partir d'où perds-tu le fil ?

J'ai bien compris que l'action ne doit pas appartenir à une classe mais doit être redirigée vers un contrôleur qui lui, fera appel à des méthodes qui feront le traitement ; d'abord, cela me suscite une question : où mettre cette action alors que le formulaire lui-même appartient à une méthode ? (en gros, ceci :

Citation:

---

Controller 1 (pour la Route 1) : tu sers la page avec le formulaire adéquate

---

Mais c'est ensuite (l'organisation) que je décroche ; d'abord, selon tes notations, je déduis que "Depense" est une classe ; pourquoi "add(array $p)" est une méthode abstraite ? Sinon, ton terme "Actions" (ligne 3), ça n'a rien à voir avec l'action d'un formulaire html ? Il y a 4 fois le terme "nouvelle demande" ; là je comprends pas trop et en plus, qu'est-ce que ça veut dire "nouvelle demande soumission" ?

Citation:

---

Envoyé par laurentSc

où mettre cette action alors que le formulaire lui-même appartient à une méthode ?

---

Le formulaire n'appartient pas à une méthode : la vue doit rester autonome le plus possible. Ne serait-ce que parce que tu peux très bien appeler le même formulaire pour deux actions distinctes : la création et la modification. Tu peux très bien passer par exemple un paramètre mode (insert|update) à ton bloc vue pour qu'il puisse se formater tout seul. Les différences entre une création et une modification peuvent être minimes et ne nécessitent pas toujours deux formulaires.

Je me rends compte que je t'embarque dans une discussion dans laquelle tu vas perdre pied assez rapidement. Tu devrais te documenter d'ébord sur l'approche MVC et la POO en PHP parce que sans ces bases, tu vas déguster.

Allez je termine mon explication :
Le concept Depense dans mon exemple est Routable et Persistent.
Clairement, cela veut dire que c'est une classe (agrégat) qui gère un Router avec des routes spécifiques ainsi qu'une table de routage (route[action] -> contrôleur) et accède aux ressources de base de données le Depense::add(array $p) (pour faire simple).
Les vues sont liées au concept mais autonomes (c'est un lien faible, elles sont interchangeables à vrai dire et doivent le rester).

Je ne sais pas si je t'ai beaucoup éclairé :roll:
Pour tes problèmes d'organisation : crayon, papier, gomme et la tête la première dans la POO puis dans le MVC.

Le MVC et la POO, j'y suis familiarisé (bien que ne les ayant encore jamais pratiqués) car depuis l'automne dernier, j'ai suivi une formation sur ZF et une sur la POO en PHP (avec le même formateur, qui assurait). Donc même si tu utilises un vocabulaire qui m'est pafois étranger (concept, agrégat, route, Routable et Persistent,...), j'arrive à te suivre. Donc je pensais m'embarquer dans une application simple (pour me faire les dents) et pouvoir me passer du MVC, mais tu sembles dire le contraire et que par exemple, l'action du formulaire serait une vue...
Ton concept, c'est le modèle du MVC ? Donc, là, tu préconises de plonger dans le MVC, mais si j'en avais saisi les concepts (formation ZF), je n'en ai jamais fait...

Citation:

---

Envoyé par laurentSc

l'action du formulaire serait une vue...

---

Non du tout. Une vue c'est une vue et c'est tout. C'est ce que j'essaie de te faire comprendre en te disant que les vues doivent être les plus autonomes possibles.
Quand j'ai mis :

Citation:

---

route[action] -> contrôleur

---

il n'y a aucun lien avec une vue. Le contrôleur n'a pas l'obligation de renvoyer une vue, il utilise ce qui est nécessaire pour satisfaire l'action et c'est tout.
Autrement dit, quand tu listes les fonctionnalités de ton sites, tu listes des actions (par exemple : connecter, déconnecter, modifier mot de passe...), tu dois juste veiller à faire correspondre à chaque action une route (url) spécifique qui une fois traitée, renverra le flux de traitement vers le bon contrôleur qui avec l'aide des couches modèle (et/ou) vue produira le résultat escompté.

Citation:

---

Envoyé par laurentSc

Ton concept, c'est le modèle du MVC ?

---

Oui.

Encore une question de débutant (en POO) : tu dis que le concept/modèle route vers les contrôleurs ; est-ce que cela veut bien dire que selon l'action choisie par l'utilisateur, ça va lancer telle ou telle méthode ? Et pour rediriger vers un autre fichier, on fait soit un lien html, soit une redirection PHP (du genre :

Code:

---

1 2 3 4

<?php header('Location: adresse'); exit(); ?>

---

Et quand je disais qu'une action de formulaire était peut-être une vue, c'est vrai que je trouvais ça très bizarre, mais du coup, il s'agit d'une ressource non prévue dans le MVC ?

Citation:

---

Envoyé par laurentSc

Encore une question de débutant (en POO) : tu dis que le concept/modèle route vers les contrôleurs ; est-ce que cela veut bien dire que selon l'action choisie par l'utilisateur, ça va lancer telle ou telle méthode ?

---

Oui, tu as le choix dans ton architecture :
- soit un contrôleur unique avec une liste d'actions : chaque action correspond en fait à une fonction du contrôleur avec un nommage plus ou moins strict :

Code:

---

1 2 3 4 5 6 7

class UserController { public function loginAction() { }   public function logoutAction() { }   }

---

- soit un contrôleur dédié à chaque action avec PHP 5.3+:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

namespace User\Controller;   class Login { public function launch() { } }   class Logout { public function launch() { } }

---

Citation:

---

Envoyé par laurentSc

Et pour rediriger vers un autre fichier, on fait soit un lien html, soit une redirection PHP

---

Ne confonds pas redirection HTML et inclusion de fichier PHP.
Le premier c'est côté navigateur et le deuxième côté serveur. Quand tu as besoin en PHP d'utiliser un fichier, il suffit de l'inclure dans ton script courant (y a aucune notion de redirection là-dedans)

Citation:

---

Envoyé par laurentSc

Et quand je disais qu'une action de formulaire était peut-être une vue, c'est vrai que je trouvais ça très bizarre, mais du coup, il s'agit d'une ressource non prévue dans le MVC ?

---

Tu as bu ou quoi ? :weird:
MVC = Model View Controller = Modèle Vue Contrôleur
Où est-ce que tu vois que la vue est une ressource non prévue dans le MVC ?

Je te conseille de re-potasser les notes de ta formation ZEND et POO.

Je ne te comprends pas très bien ; d'abord le concept/modèle, selon l'action choisie par l'utilisateur, va faire apel à telle ou telle méthode (du ou des contrôleurs) via sa table de routage, donc il s'agit bien d'un fichier php qui va en utiliser un autre ; et tu dis qu'il n'y a pas de redirection et qu'il suffit d'inclure les fichiers ; comme ce n'est évidemment pas ça, j'ai pas compris...
Ensuite, là où j'aurais bu...:D : évidemment que dans une architecture MVC, il y a des vues ; mais simplement, on disait que l'action d'un formulaire n'est pas une vue, donc je me demandais juste qu'est-ce que c'était ?

Le concept est une subdivision du Modèle. Oublies le concept et penses uniquement Modèle. Le modèle est le nom générique pour regrouper tout ce qui est propre au métier de l'application.

Citation:

---

on disait que l'action d'un formulaire n'est pas une vue

---

Le formulaire n'a pas d'action. Il est isolé et en bout de chaîne dans ton traitement. Faut le laisser tranquille, il ne fait que le rendu et pas plus.

En faisant simple et concis :
- Pour chaque action de ton application (créer, modifier, supprimer...) tu dois faire correspondre une route (url)
- Pour chaque route de ton site web tu dois faire correspondre un contrôleur

De là tu peux en déduire que :
- Pour chaque action de ton application tu dois avoir un contrôleur

Enfin, chaque contrôleur dispose de l'ensemble du code de ton site pour parvenir à exécuter ce pourquoi il est prévu.
S'il doit créer un enregistrement, il fera appel à la couche d'accès aux données.
S'il doit renvoyer un formulaire pour une saisie, il incluera le formulaire adéquate et le renverra en guise de réponse.
S'il doit générer un PDF, il initialisera la librairie PDF et pourra transférer le traitement à une routine dédiée pour la création du fichier PDF.

Bref, diviser pour mieux régner.
Après il faudrait se plonger dans un cours théorique sur le MVC (mais là j'ai pas vraiment le temps tu vois).

Citation:

---

Le formulaire n'a pas d'action

---

Certes, pas au sens "MVC", mais il y en quand même une :

Code:

---

1 2 3

<FORM METHOD="POST" ou "GET" ACTION="url" ENCTYPE="---"> ... </FORM>

---

et c'est de ça que je parle.

Ce que j'ai compris : depuis le modèle, l'utilisateur peut choisir entre plusieurs actions ; pour chacune d'elles, il y a une route (en fait une méthode d'un contrôleur).

Mais un truc que je ne vois pas : le modèle propose plusieurs actions et pour chacune d'elles, une méthode d'un contrôleur, mais comment appeler celle-ci vu que l'objet "contrôleur" n'appartient pas au modèle ?

Citation:

---

Envoyé par laurentSc

Ce que j'ai compris : depuis le modèle, l'utilisateur peut choisir entre plusieurs actions ; pour chacune d'elles, il y a une route (en fait une méthode d'un contrôleur).

---

ou un contrôleur dédié.

Citation:

---

Envoyé par laurentSc

Mais un truc que je ne vois pas : le modèle propose plusieurs actions et pour chacune d'elles, une méthode d'un contrôleur, mais comment appeler celle-ci vu que l'objet "contrôleur" n'appartient pas au modèle ?

---

C'est pas le modèle qui appelle le contrôleur mais le contrôleur frontal de ton site.

Voici une explication :
- Ton site doit avoir un point d'entrée bien défini : ex: index.php (cela veut dire que tu rediriges toutes les requêtes vers index.php)
- Dans le code de index.php, tu vas instancier une classe spéciale FrontController() qui va se charger d'analyser la route afin de trouver le contrôleur qui en est responsable.
Pour cela, le FrontController va parcourir les tables de routages, comparer la route avec toutes celles définies, et si une correspondance est trouvée, s'arrêter et récupérer le contrôleur rattaché.
Ensuite il va instancier ce Contrôleur et lui passer la main afin qu'il puisse fournir une réponse appropriée à la requête.
Une table de routage ce n'est rien de plus qu'un mécanisme qui stocke des paires : route -> (controller, action) (en simplifié)
Une fois la réponse construite, le contrôleur peut rattacher la réponse au FrontController qui se charge de l'envoyer (pas toujours, ça dépend des fwk).

Voilà un bref résumé. On pourrait aussi y passer la nuit tant les subtilités sont nombreuses.

Merci d'avoir tenté de m'expliquer, mais je constate que je n'ai pas le bagage suffisant pour suivre. En gros, il faut forcément passer par le MVC, donc éventuellement recourir à un framework, qui fera le gros du boulot, même s'il est nécessaire d'en connaître la philosophie ; c'est aussi ton avis ?

http://symfony.com/doc/current/book/..._symfony2.html

Merci pour le lien (qu'on m'avait déjà donné, mais pas encore étudié (essayé, mais abandonné)). Mais j'aimerais d'abord me faire les dents sur la POO sans framework, afin d'assimiler d'abord cette technologie ; ça doit être possible ; comment s'y prendre (sachant que j'étais parti sur un truc visiblement trop complexe) ?

Citation:

---

Envoyé par laurentSc

En gros, il faut forcément passer par le MVC, donc éventuellement recourir à un framework, qui fera le gros du boulot, même s'il est nécessaire d'en connaître la philosophie ; c'est aussi ton avis ?

---

Forcément non, il existe toujours d'autres alternatives mais l'approche MVC a fait ses preuves.
Il n'est pas juste nécessaire mais obligatoire de connaître la philosophie.
Tu ne comprendras pas le code d'un framework si tu ne vois où ceux qui l'ont codé veulent t'amener.
Plus généralement, tu coderas d'ailleurs plus vite et mieux en ayant bien compris le schéma directeur d'un modèle de développement que sans avoir pris le temps de le dépieuter et de te l'approprier.

En basant le développement sur des concepts abstraits comme le MVC, la maîtrise de la théorie est vitale, sans elle et même avec une bonne pratique du langage tu passeras ton temps à tatonner au lieu de vraiment avancer dans la bonne direction.
Et c'est tout aussi valable pour la POO.

Il n'y a pas à tortiller, le "gomme-crayon-papier" est toujours d'actualité.

Bien noté, mais n'ayant jamais pratiqué ni FWK, ni POO, je voudrais déjà assimiler la POO avant de passer au FWK. Est-ce possible ? Et si oui, aurais-tu un exemple d'appli simple, donc faisable en POO sans FWK ?

Citation:

---

Envoyé par laurentSc

je voudrais déjà assimiler la POO avant de passer au FWK. Est-ce possible ?

---

Bien sûr.
La POO est la base de tous les frameworks modernes.
Pour maîtriser un framework, il faut d'abord maîtriser correctement la POO.
Et ne prend pas pour objectif d'apprendre la POO avec un framework, c'est quasiment impossible dans la mesure où les frameworks utilisent les bases et les subtilités de la POO.
Sans compter que leur documentation ne s'arrête qu'à l'implementation des aspects fonctionnels et ne fournit aucune explication sur le pourquoi du comment.
Tous les frameworks modernes posent comme prérequis la maîtrise de la POO.

Bref : yapuka :ccool:
Tu vas trouver pléthores de sites et de livres qui vont t'expliquer pas à pas les principes de la POO (d'ailleurs tu peux attaquer par dvp).