Reprise du message précédent :
Ca y est, nouvelle version de solar. Ils ont eu l'idée de déterminer le format de la view à partir de l'extension de l'url.... Ca fait 6 mois que c'est implémenté dans mon truc, ch'uis trop fort

J vois pas l'interet de decouvrir le format de view au lieu de la forcer

avoir des url faciles a retenir, genre www.monsite.com/page.html et www.monsite.com/page.pdf, ce qui est plus transparant pour l'utilisateur.

Tin mais le gars de solar avait une DP fever. Qu'est ce tu vx adapter en HTTP !!

Ouh yeah. Là j'ai fait un module diaporama, tu peux appeller le truc de différentes manières :

Version XHTML normale

Version servie en application/xhtml+xml + prologue xml, parfait pour remplacer tout un bloc via DOM + ajax

Xml pur (balises spéciales, utile pour l'ajax)

Génère un script qui gère le diapo.
 
 
Du coup côté implémentation, je fais dans une page un lien vers le diaporama. Le diapo s'ouvre dans une nouvelle page, affiche l'image courante + boutons suivants précédents. Dans la première page, j'appelle le script qui remplace le lien par le diaporama lui-même (via la version xhtml), et greffe des events sur les liens pour récupérer une nouvelle image à partir du XML Graceful degradation at its best : ceux sans JS verront un lien, ceux avec auront le diaporama directement. Si j'ai le temps j'uploaderais un exemple

Jusqu'a preuve du contraire l'utilisateur trouve une ressource >>> manipule ressource.

D'ailleur donner a l'utilisateur du controle sur l'application via le controle URL me parait irrealiste.

Faudrait ptetre eviter de mettre les utilisateurs a sont niveau

supermofo, tu veux que en gros lorsqu'un utilisateur va sur un site, il click et se fou des urls, c'est ca ? car , je comprends pas ce que tu entends par ressouce.
 
mais si c'est ca, je suis d'accord. perso, je me fous de la tête de l'url, car souvent, on tape le nom de domaine et rien de +

Ouais on clique sur des liens bien visible et si possible organises de maniere intuitive.

Anecdote:

X arrive de google sur un site  avec mot cle : biggest dog
1min apres
Le meme X revient sur le meme site avec mot cle : big dog
Et encore une fois avec mot cle : picture big dog

Tout ceci en repassant a chaque fois par google  

C'est pourtant constamment le cas... Si moi j'utilise l'extension pour définir le format généré, d'autres utiliseront un paramètre...

Par utilisateur j'entend "user" c est a dire le gars qui arrive sur le site, qui fait ces clics et puis s'en va.
 
En parlant de parametre URL tu me conseilles quoi entre :
 
- chaque module definit ses parametres ( style fichier config )
- une factory d objet parametres
- gerer ca a plus haut niveau ( dans le front par exemple )
 

Moi chaque controller définit ses paramètres dans la fonction correspondante à la méthode HTTP :

Et le paramètre est repris de l'url. On peut mettre plein de paramètre, faudra les passer séparés par des /. mod_rewrite pour zéro dollars

C'est marrant, on dirait web.py mais en moche
 
edit: histoire de montrer de quoi je parle, quand même, le "contrôlleur" d'une application web.py ressemble à ça:
 

import web
 
urls = (
    '/', 'index',
    '/add', 'add',
    '/delete', 'delete',
    '/update', 'update'
)
 
render = web.template.render('templates/')
 
class index:
    def GET(self):
        todos = web.select('todo')
        print render.index(todos)
 
class add:
    def POST(self):
        i = web.input()
        if i.title.strip():
            n = web.insert('todo', title=i.title)
            web.seeother('/#t'+str(n))
        else:
            web.seeother('/')
 
class delete:
    def POST(self):
        i = web.input()
        web.delete('todo', int(i.id))
        web.seeother('/')
 
class update:
    def POST(self):
        i = web.input()
        if i.content.strip():
            web.update('todo', int(i.id), title=i.content)
            print i.content
        else:
            print web.select('todo', where=("id=%d" % int(i.id)))[0].title
 
if __name__ == "__main__": 
    web.run(urls, globals(), web.reloader)

Ah ouais quand même  

J'ai l'impression de voir un de mes controlleurs Ruby

Sinon, je commence à m'intéresser au MVC de près, seulement j'ai commencé prendre le problème dans l'autre sens.
En effet, je ne peux pas imposer le MVC (fait maison ou basé sur un framework quelconque) d'un coup au boulot...

Donc j'ai commencé par bosser sur des helpers, déja j'ai un peu simplifié l'interface PHP/SGBD (malheuresement la prod est en PHP4),ensuite je vais ajouter des méthodes style update(), save(), find(), ect...

J'ai une classe form (extension future de la classe html, ou faut-il tout mettre dans la classe html?), dont je me sert pour les backoffice, afin de minimiser les temps de prod. C'est à mon avis aussi à inclure dans la structure MVC, mais ça soulève un autre problème (voir 1)

Je pense bosser sous phpontrax, ça m'a l'air pas mal du tout, j'aime bien la syntaxe ruby like.
(1) CakePhp est pas mal aussi, mais j'aimerais bien savoir à quel degré on doit séparer les couches, parce que la contrairement à POT, ils utilisent une classe qui sort du html, et forcément, il on du code php directemet dans la vue.
 

Donc c'est UN controleur qui tape dans les variables du serveur web Bien pour l'indépendance de l'appli et le point d'entrée unique

> leflos5 : tu en connais d autres des points d entree en HTTP ? Dans tous les cas a un moment ou a un autre tu dois recuperer ces variables serveur. Le tout est d encapsuler  une bonne fois pour toute, et la solution repond a ce critere. Apres je dis pas, faut voir ce qu il se passe dans les autres parties.

J'ai vu un truc pas mal sinon tire d'ajax mais ca me parait overcomplicated pour un framework model2. ( Stroboscope Web )
Vu les limitations de javascript les gars trouvent trouvent de jolies solutions assez souvent.

Si j etais motive j'aurais fais un observer:

Mais comme je suis une grosse feignasse je fais:

Les taches des modules sont clairement definies dans leur classe donc pas la peine qu' ils aillent decouvrir ce qu il doivent faire.

Par contre comment faire pour que Control ne se ballade pas partout dans le model ? Beaucoup de logique dans le controller, des chips ?

Le point d'entrée unique est justement le contrôlleur qui sert d'interface entre le serveur web et l'application, couillon

Comme quoi personne ne comprends rien au mvc et tout les termes à la noix qui vont avec
 
On croirait entendre un discours de ssii, tma, mao,...

En meme temps on a pas besoin d'etre serieux ( a la limite je trouve ta remarque vachement deplacee ).

Tiens j'ai des questions existentielles sur le MVC :  
 
- pour la partie Controller, j'utilise un FrontController avec des Page Controller. Mais comment scinder les actions de ces Page Controller : un pour chaque page ? un pour chaque domain logic (genre un page controller pour tout ce qui touche les utilisateurs, etc, ...) ? Autre ?
 
 
- Souvent pour l'affichage d'une page, y a plusieurs actions à lancer sur le modèle (par exemple, pour la page d'accueil d'un forum on pourrait vouloir afficher la liste des derniers threads, et la liste des utilisateurs, 2 actions bien distinctes sur le Model). Il me semble que ce n'est pas au controller de faire cet "assemblage" (par exemple récupérer du Model une liste de threads, une liste de users, et balancer les 2 listes à la vue) : ça ferait du controller un médiateur, et surtout ça serait vite le bronx.
 
Alors que faire ? Ne faudrait-il pas créer une classe qui gère ces actions composites (par exemple une classe Forum. Le controller lance une unique action sur un objet Forum, qui récupère la liste de threads et la liste de users. Puis le controller balance l'objet Forum à la vue). Mais ça implique de devoir créer une classe de plus "haut niveau" à chaque fois qu'on a besoin de plusieurs actions sur des classes "bas niveau". Ca vous semble censé ?
 
 
- La vue : ne doit-on pas impliqué à la vue les mêmes principes ? Par exemple, une classe User_View qui gêre d'afficher des liste d'utilisateurs de 50 manières, d'afficher les infos sur un utilisateur, etc, ... une classe Thread_View qui gêre d'afficher des listes de threads de 50 manières. Et au final, une classe Forum_View qui gêre d'instancier un objet User_View, un objet Thread_View, et qui les utilise pour afficher la page d'accueil.
 
 
So ?
 
(l'exemple est bidon hein, juste histoire d'illustrer mes propos peut-être tout aussi bidons)

Je dirais bof. Tu fais de ton controleur et de ta vue des miroirs de ton modèle, en faisant ça...c'est l'inverse du but recherché.

La vue doit avoir une architecture en relation avec les problématiques propres à la vue, quel que soit le modèle derriére...idem pour le controleur.

[edit]

Après si ça a un sens, ça peut rester assez proche, mais faut pas que ce soit sytématique, quoi...

Tu pourrais montrer comment gêrer ce genre de cas selon toi stp ? J'ai vraiment du mal sur l'organisation du controller et de la vue.

EDIT DE OUF ...

Indentation bordel

OSEF, on est pas en python
 
 
 

Justement, le PHP c'est déja moche indenté alors sans indentation c'est cauchemardesque

J y peut rien moi, faut voir ca avec le soft du forum

Le soft du forum fonctionne très bien, prière d'arrêter de se chercher des excuses

Skeye ? FlorentG ?

flemme de répondre point par point...
 
Dans mon bouzin (loin d'être parfait,hein...je ne te présente qu'une vision des choses, pas la vérité absolue), le contrôleur et la vue sont très très light.  
 
La couche contrôleur peut au final être vue comme une sorte de fonction main(). Tu lis l'input, et tu instancies le modèle et la vue en fonction de ce que tu as lu...c'est très procédural, comme approche, finalement.  
Et donc pour reprendre ton exemple, pour moi, c'est bien le rôle du contrôleur d'aller chercher dans le modèle la liste des users et de la passer à la vue si elle en a besoin...si ce n'est pas lui, alors qui va la lui donner?
 
Ensuite, la vue, dans mon machin, on peut presque la réduire à smarty, pour l'affichage html...le controleur lui file les données, et elle connait le(s) template(s) à instancier...partant de là elle n'a plus grand chose à faire...

Ha ouais non mais ça on bien d'accord hein ^^
 
Ma question c'est plutôt : quand on a plusieurs actions à lancer sur le Model, est-ce que c'est le Controller qui va lancer ces différentes actions, et passer donc plusieurs paramètres à la Vue. Ca me semble tout nase ça.
 
Je me disais donc qu'il valait mieux créer une classe du Model, qui lancerait ces différentes actions. Le Controller n'aurait ainsi que une action à lancer sur le Model, et un seul paramètre à passer à la View.
Pour moi, ça fait sens même conceptuellement. Dans mon exemple tout bidon, un forum c'est bien des posts et des users, pas de problème à créer une classe qui s'occupe de lister les posts et les users.
 
Mais y a plein de fois où c'est plus tordu de trouver un lien conceptuel. Bref, là question :  
Le controller lance plusieurs actions pour une page, ou il faut faire intervenir une classe du Model de niveau supérieur ?
 
 
(Mon idée c'est donc qu'il y a des classes de "base" dans le Model, très corrects d'un point de vue conceptuel, et des classes à un niveau "supérieur", toujours indépendantes du Controller et de la Vue, mais un peu plus adaptées à eux.)

A quand un tuto documenté pour illustrer tout ca avec des exemples concrets ? parce que la c'est le flou total    

 
Ah non. Ca revient à faire ton modèle en fonction de la vue, ça.
Tu déportes le controleur dans ton modèle, là...
 

 
Le controleur instancie autant d'objets du model qu'il en faut pour alimenter la vue.
Par contre pour reprendre ton exemple, le listage des utilisateurs ça peut être une fonction statique de la classe user, qui retourne une liste d'users...ça me gêne absolument pas qu'une classe user dispose d'une fonction retournant une liste d'users...
 

 
Dans ce que tu postes, je ne vois pas le "indépendantes du controleur et de la vue"...

Oki merci pour les réponses, je faisais comme toi avant mais ça me semblait nase ^^
 
Et au sujet de la Vue :  
toujours dans ce même ordre d'esprit, en reprenant l'exemple du listing  des users et des posts d'un forum, ça te paraît correct ça ?
- une classe Display_User qui sait afficher une liste de users de 50 manières.
- une classe Display_Post qui sait afficher une liste de posts de 50 manières.
- une classe Display_Forum, qui utilise les 2 classes précédentes pour afficher un résumé du forum.
 
Ca serait toujours dans l'esprit d'avoir des classes de "base" qui font des choses de "base", et des classes au dessus qui savent les assembler pour obtenir les pages.
 
Ou tu penses aussi que c'est au Controller d'assembler différentes vue pour générer la page ?
 
 
(sinon, pour une fonction statique de la classe User retournant une liste de users ... moi ça me gêne. Un objet User, ça représente un et un seul user. Pourquoi cet user irait-il connaître les autres ? Ca me semble un peu bancal ^^)

 
Je pense que le soucis qu'on a c'est que tu vois le controleur comme un gros bloc avec un seul point d'entrée vers le modèle, et un seul point d'entrée vers la vue, et moi non.
Pour ton cas, je verrais plutôt un truc dans ce genre, au niveau du controleur :
1) La classe "principale" analyse la requête, et instancie...
2) ...des classes du controleur "spécialisées", en fonction de la requête.
Une de ces classes va aller instancier ce qu'il faut dans le modèle pour récupérer la liste des utilisateurs, et instanciera la classe d'affichage correspondante.
3) C'est gagné...la classe "principale" n'a plus qu'à demander aux classes "spécialisées" de lancer l'affichage...
 
Partant de là, ton Display_forum n'a plus lieu d'être...et c'est bien uniquement le controleur qui sait que pour afficher le forum il faut afficher à la fois les users et les posts, comme prévu.
Tu noteras que cela ne correspond pas du tout à mon archi perso, qui est un peu (voire très) batarde.
 

 
M'enfin ça sert à quoi d'après toi les méthodes statiques?

Oki merci, bon bah c'est ce que je faisais mais je me demandais si c'était bien le rôle du controller. Mais c'est vrai que tes arguments se tiennent, et qu'on a ainsi une réusabilité maximale de la vue et du model.
 
 
Les méthodes statiques à mon sens c'est surtout utile pour certains design pattern (genre singleton), et pour des méthodes qui doivent pouvoir être utilisées de n'importe où dans l'appli.
 
Je me répète mais je vois pas pourquoi une classe user devrait connaître les autres users :
Si on a une appli de vente de voitures, ce n'est pas à une classe Voiture de connaître l'état des stocks des voitures ... c'est le boulot d'une classe Stock.
Pour un journal en ligne, ce n'est pas à une classe Article de connaître la liste de tous les articles, mais bien à une classe Journal.
 
'fin bon ce n'est que mon avis de noob, si tu as des trucs pour me montrer que j'ai tout faux je suis preneur

Ca ne veut rien dire, ça.
C'est une méthode statique, tu ne l'utilises pas avec une instance de ton objet, mais avec l'objet lui-même.

[edit]

Pour reprendre ton exemple, ce sont des infos sur les voitures, qu'il lui faut, quand même, à ta classe stock...elle va faire comment, pour les obtenir, elle va demander elle-même à la base de données ou à la classe qui gère les accès aux données? Ou alors elle demande poliment à la classe Voiture de bien vouloir lui fournir les infos qui la concernent?

bah, ça veut rien dire ça ?  

Il me semble que c'est un argument conceptuel valable. Mais je serai heureux d'avoir les tiens : qu'est-ce qui justifie d'après toi qu'une voiture puisse gérer un stock ? Pourquoi ne serait-il pas plus approprié de créer une classe Stock ?  
 
Et si tu as des liens expliquant pourquoi il est mieux de rajouter à une classe Voiture une méthode statique gérant le stock (ou autre exemple), je suis preneur
 
J'ai pas la science infuse hein, mais c'est sur ce mêne forum qu'on m'avait expliqué ce que je suis en train de raconter.

cf mon edit.
La classe voiture ne gère pas les stocks, elle fournit les informations qui concernent les voitures.

Bah oui, la classe Stock va interroger la classe qui gère les accès aux données, qui va lui retourner une collection d'objets voiture. Qu'est-ce qui n'est pas valable là-dedans ?

Dans la pratique, ton instance de Stock va être initialisée en faisant appel à la méthode statique de la classe Voiture, et à-partir de là elle fait sa tambouille toute seule.
Mais à-partir du moment où elle lit ou met à jour des infos concernant des voitures, elle doit passer par la classe Voiture.