Zend FR

/contact  controller

faut pense que t'a les index

http://www.example.com = http://www.example.com/index

si tu veu une page contact a la racine  fait

http://www.example.com/index/contact

stealth35, justement je ne .veux pas de http://www.example.com/index/contact
Comment créer une page à la racine. Un truc aussi simple que ça, je ne sais pas comment faire.

nicko, si laune est un controller ainsi que foot... que sont /france et /l1 ?

Merci.

Tu peux faire
http://www.example.com/contact

C'est à dire que contact est un controller...
Un controller par page... moyen...

Et que faire avec les structures de niveaux inférieurs type /france et /l1 ?

Oké j'vais me pencher la dessus.
Tu me confirmes qu'il est possible d'avoir une page à la racine d'un site en jouant avec les routes ?
http://framework.zend.com/manual/fr/zen … outer.html
La page est costaud je prendrai de la lire plus tard.

En gros, la routes par default du ZF est sous la forme http://monsite.com/:controller/:action/ … mN/valeurN

Avec la propriété suivante :
Si tu accèdes à la page http://monsite.com/, cela revient à appeler la page http://monsite.com/index/index (controller = index, action = index)

Donc si tu veux une page http://monsite.com/contact, tu peux :
- créer un action contact dans ton controller index => http://monsite.com/index/contact
- créer une page index dans ton controller contact => http://monsite.com/contact/index
- créer ta propre route en précisant par exemple que http://monsite.com/contact pointe sur http://monsite.com/relactionClient/contact (controller = relationClient, action = contact)

Voilà, j'espère ne pas t'avoir perdu.

Le plus efficace reste tout de même de lire la doc et te faire différente tuto de quickstart (practice, practice, practice again)

Dernière modification par slaughter (11-09-2009 10:36:54)

Il suffit d'aller lire la documentation. Le composant Zend_Controller_Router_Route permet de définir les routes comme on le souhaite. Les routes et le mvc n'a rien à voir quelque part, car tu peux former les routes comme ça te chante. Il suffit de traduire cela en module, contrôleur, et action après coup. Tu as plusieurs types de routes : static, regex, standard, etc.

Pour des pages comme contact, login, etc peuvent être réalisées avec Zend_Controller_Router_Route_Static par exemple.

L'organisation d'une structure MVC ne se raisonne pas de cette manière. Il faut plutôt passer par de l'UML pour regrouper les notions/ressources qui ont des liens entre elles. Sekaijin avait proposé une explication dans un post du forum, il me semble.

Une vison récurrente est d'avoir un contrôleur CRUD. Le contrôleur représente une ressource comme un sujet de forum par exemple. Les actions sont lire, écrire, supprimer, éditer, etc.

Qu'attends-tu au juste d'une url comme http://www.example.com/sport/foot/france/l1/classement ? Quelle ressource est concernée ? quelles parties sont des paramètres ?
Si tu présentes des résultats de différents sports, un sport pourrait être une ressource. Si tu as un modèle et traitement générique selon les sports, la France est une nation, le foot un type de sport, la ligue 1 une division. Le classement pourrait être une action. Tu pourrais considérer afficher des classements d'une division d'un sport de manière similaire ou selon des paramètres propre à chaque sport.

Tu devrais peut-être revenir en arrière : mettre de côté la programmation, et ressortir une feuille. Tu fais des scénarios d'utilisation, des schémas, de l'UML et/ou autre méthode pour formaliser tes idées/besoins. C'est plus facile de raisonner de façon ordonnée.

EDIT : j'ajouterai que la génération des urls vient en aval et non en amont. Tes besoins/scénarios détermineront les URL. L'URL rewriting pour favoriser le référencement et l'utilisation expert d'URL sont des masques qui doivent renseigner les informations nécessaires à l'aiguillage (module, contrôleur, action, params).

Le fait d'avoir http://localhost/login au lieu de http://localhost/auth/login est une utilisation experte pour moi. Mais ce n'est pas très organisé de constituer un contrôleur login, un autre logout, car login et logout sont des actions d'un contrôleur Auth. Auth est la ressource identité d'un visiteur. Login et logout correspondent à créer et à supprimer cette identité. Il semble assez logique de les regrouper.

Dernière modification par Intiilapa (11-09-2009 20:50:26)