Reprise du message précédent :
rien, quand j'en saurai plus je serai peut être a même de poser des question pertinentes. salut

J'ai une classe "panier" dans la session, sans BDD derrière.
 
(en fait c'est pas complètement vrai, c'est pour comprendre )

Ben perso je foutrais le panier en DB, ça permet à l'utilisateur de conserver son panier entre deux sessions

C'est le cas, mais seulement si il est loggé
(Du coup, la BDD n'est qu'un accessoire de sauvegarde et la logique joue principalement sur la session)

S'il est pas loggé tu crées un user temporaire associé à sa session, et tu bind son panier à ce user

Et ça m'apporte quoi de plus que de le mettre en session, à part de moins bonnes perfs et un design plus compliqué ?

L'unification de la gestion du panier (et du reste d'ailleurs) entre un user identifié et un user "anonyme".

edit: et la seule complication au design, il est au niveau de la considération/identification de l'utilisateur (qui est normalement indépendant du reste), tout le reste de l'application se trouve simplifié, puisqu'on se retrouve avec un utilisateur dans tous les cas.

Ya aussi qu'il me faut créer un système d'utilisateurs "temporaires", et les vidages de tables réguliers etc que ça impose...

Franchement, faire de l'unification au prix d'un code plus compliqué, pas question à mon sens. Par contre, avoir des algorithmes adaptés aux besoins et à la situation, je suis 100% d'accord. Unifier, oui, mais avec modération

Tout ce que fait pmjones est du bonheur. D'ailleurs si t'as le temps, jette un coup d'oeil sur son package Modele.
 
 
 

Ah j'avais pas vu que c'était lui Il est aussi à l'origine de Solar

Bonjour,
Que pensez vous de l'utilisation des exceptions comme moyen de redirection interne permettant d'effectuer des actions chaînées.
Un exemple pour illustrer ma pensé :
 

J'en pense pas trop trop de bien, j'aime pas le détournement des exceptions pour autre chose...Si tu veux chainer des actions en fonction d'un événement tu as des patterns genre chain of responsability non?

J'en ai pas vraiment compris l'application en PHP...

l'application de quoi? de chain of responsability, ou des exceptions?

De "chain of responsability", en réalité, j'aimerai qu'une action peut passer la main à un autre action et ainsi de suite selon certain cas mais sans les définir au préalable comme par exemple instancier une action A, B et C, faire un foreach et executer une méthode...
 
J'en profite pour rajouter ces questions :
- front controller, unique point d'entrée d'une application, mais est-ce lui qui détient les set/get pour les différentes classes du système comme request, response, router, dispatcher, i18n etc..  
- action controller ou page controller ? un controller peut avoir plusieurs actions soit on dit "action controller" sinon "page controller" ?
- et pour application controller ? c'est juste une extension du front controller rajoutant quelques méthodes ?
- qu'est qu'une classe "context" comme celle de symphony ? est-ce le même que l'object abstract request de Zend ? Qui set/get réellement le nom du controlleur, de l'action et des paramètres à invoquer, ne serait-ce pas le dispatcher car après tout c'est lui qui délègue vers le controller qui execute une action... ?

Bah c'est pareil dans tous les langages, non?
D'ailleurs c'est le principe utilisé par les exceptions, en fait...elles remontent le long de la chaine (ici la pile d'exécution) jusqu'à tomber sur un handler qui va bien (le catch).

pour les questions supplémentaires, je passe mon tour

un do {} while(); avec une variable booléenne comme le fait zend... mais j'aime pas le faite qu'on se serve de l'objet requête pour stoker le nom de du controller et de l'action.

Chez moi la classe Context contenait la requête, la réponse, la session, etc. Mais j'ai fini par tout balancer pour simplifier.

Donc tu pouvais les set/get ?  
 
J'aimerais n'avoir qu'à effectuer Controller_Front::execute('path/to/application'); pour exécuter mon application.
 
Le Front controller, se servirait d'une requête Http, analysé par un router passant le résultat de cette analyse au dispatcher pour instancier le controller demandé.
 
Ce controller, hériant d'une classe de base Controller_Action, exécuterait une méthode preExecute, l'action et postExecute.
 
Les filtres seront exécutés par le Front controller avant et après le dispatchage.
 
Mais la question que je me pose est ou stocké le nom du controlleur et de l'action afin de permettre un "forward"... et comment l'effectuer ?

Moi pour tout ce qui est machins un peu globaux comme ça, j'ai un Service Locator dynamique : j'peux charger des services et en définir une instance comme accessible statiquement. Si je garde l'instance quelque part j'peux modifier les services, utile pour les tests unitaires.

Comme le "registry pattern" en somme ? mais ou fais-tu ta première instance ? celle qui initialise ton objet pour ensuite l'enregistrer ? permets-tu l'extension de cette objet au travers de ton front controller ?

J'ai un objet qui se charge de le configurer avant de lancer le Front Controller

Comment ça ? dans un fichier de configuration tu mets le nom des classes à utiliser pour un service et ce fichier tu le passes au front controller ?

Nan, j'ai une fonction qui initialise tous les services selon les besoins.

Hametsu > Si ça peut t'aider, j'ai fait un petit framework vite fait avec Front Controller, chainage de filtres, Routeur PHP, internationalisation,  
moteur de templates à base de PHP etc.
 
Lien pour le download : http://rapidshare.com/files/114367 [...] k.zip.html
 
Crée toi en local un dossier /framework (sous wamp par exemple) et place le framework dedans. Puis va sur l'url :
http://localhost/framework/default/index
Sinon, si t'as envie de tweaker un peu t'as le fichier de conf général du framework dans /conf.

Merci l'ami, je vais "tweaker" ça
 
PS: c'est quoi ce mot o_O¿

"tweaker" signifie modifier en gros.

du coup twinky winky veut dire...
 
 

bon , je suis (enfin ) en train de refactorer le coeur du CMS sur lequel je bosse ( php4/mysql3 ) pour le faire passer a php5 mysql5 , et surtout, aux classes, au lieu d'avoir des fichiers de plus de 3 000 lignes de codes  mélangeant SQL , js, php et HTML  
 
 
voila en gros la solution sur laquelle je pars
 

• un front controler : chargé d'instancier le bon "module" ( GED, agenda, planning, groupe de travail, .... )  
• un  niveau en dessous de contrôleur, chargés  de gérer les actions au sein d'un module ( ajouter un rendez vous pour un agenda , supprimer une page)  

par contre, j'ai du mal a voir, qui doit gérer les droits d'accès ?  
ca se fait au niveau du modèle ou du controleur ? j'aurai plutôt dit que c'est à la charge du controleur , mais j'ai un doute

Moi je dirais modèle. C'est même mon modèle qui charge les privilèges avant de charger les données.

Chez moi y en a un partie dans les controlleurs (tel profil a droit à telle ou telle action...).
J'en ai aussi dans la vue (tel profil à le droit de voir telle infos, genre une colonne de plus dans un tableau).

En fait, le modèle a pour charge d'aller chercher ses propres privilèges en fonction de l'utilisateur courant, et des fonctions rapportent ce qu'il a le droit de faire. Le contrôleur se contente de faire passer l'info, la vue se contente de lire ces infos

On peut aussi avoir une surcouche (par contre je sais pas comment exprimer ça en PHP): dans django, on peut spécifier que certaines vues ne sont accessibles qu'avec certains droits via une annotation:

une vue normale est une fonction classique

def myview(request):
    # do stuff

on peut checker manuellement e.g. que l'utilisateur est loggé ou qu'il a bien une perm précise

def authenticated_view(request):
    if not request.user.is_authenticated():
        return HttpResponse("fail" )
    # do stuff
 
def permissioned_view(request):
    if not request.user.has_perm("epic.win.man" ):
        return HttpResponse("fail" )
    # do win stuff

Mais c'est sale, ça inclue le code de vérification dans la vue alors que celui-ci est en réalité placé à un niveau plus haut.

Donc on peut utiliser des décorateurs qui gèrent la partie droits plus simplement, plus clairement et évitent de le coller manuellement dans les vues:

@login_required
def authenticated_view(request):
    # do stuff, only logged-in users can reach this
 
@permission_required("epic.win.man" )
def permissioned_view(request):
    # do stuff, only epic win men can reach this

Et bien sûr, comme les décorateurs python sont en fait de simples HOFs, on peut déplacer ces appels dans le dispatcheur d'url si on veut pouvoir utiliser une vue donnée dans des cas différents, certains devant être protégés et d'autres non

edit: of course, si on a besoin d'un truc plus fin, genre un traitement différent en fonction de certains droits et non juste autoriser ou refuser l'accès à une vue, on peut revenir à une vérification manuelle via l'objet User comme en haut.

c'est vrai que le modèle peut prendre en charge le fait que l'user ai accès ou non aux données, mais a ce moment, là, une partie des droits va dans la vue aussi , et ca me gène de séparer ça un peu partout
 
c'est déjà bien le bordel la gestion des droits, donc si je pexu centraliser

 
ca me semble être le plus simlpe a programmer, mais quelque part, ca me gène  
 
Dans ce cas là , je ferai qq chose comme ça :
controler.php  

switch($action)
{ 
     case 'edit':
               if($user->canEditFolder($idFolder))
               {
                      $folder = new FolderModel($idFolder);
                      $flagAdmin =  $user->canAdminFolder($idFolder);
                      $view = new FolderEditView($folder,$flagAdmin);
                      $view->show();
              }
              else
              {
                     $view = new ForbiddenFolderView();
                     $view->show();
              }
}

 
histoire que la vue sache si il faut afficher les outils d'admin ou pas, mais sans savoir pourquoi . Il n'y a que le controleur qui fait le lien .
 

def myview(request):
    # do stuff

def authenticated_view(request):
    if not request.user.is_authenticated():
        return HttpResponse("fail" )
    # do stuff
 
def permissioned_view(request):
    if not request.user.has_perm("epic.win.man" ):
        return HttpResponse("fail" )
    # do win stuff

@login_required
def authenticated_view(request):
    # do stuff, only logged-in users can reach this
 
@permission_required("epic.win.man" )
def permissioned_view(request):
    # do stuff, only epic win men can reach this

 
ça se fait pas tout à fait  de la même manière en PHP, mais j'avoue que ça me gène que la vue doive savoir que l'user est bidule truc ou machin, ou qu'il a le droit de pisser contre le vent sans salir ses chaussures
Je préférerai dire a la vue les paramètres qui sont nécessaires plutôt que lui laisser le choix

bon en fait, je viens de trouver un contre exemple  
 
sur les dossiers "normaux" j'affiche en contenu la liste des sous dossiers accessibles ( profondeur arbitraire, le records est a 4 ) pour des raisons d'accessibilité et de remplissage  
Les dossiers auxquels ont a accès sont affichés sous forme de liens, pour les autres , il s'agit juste du titre du dossier, non cliquable
 
si la vue et le controleur ne doivent pas voir la partie "droits,  il faut que je passe en paramètres tous les droits

j'ai rien compris \o/

Mais pourquoi la vue et le contrôlleur ne verraient pas la partie droits? Chez moi (enfin dans Django plus précisément) la vue et le template (ya pas de contrôlleur dans django, enfin pas vraiment, disons que l'interaction du programmeur avec le controlleur django c'est habituellement juste de définir l'url dispatching) ont accès au user courant, et via ce dernier à ses perms & autres (et pour simplifier les templates, les perms du user courant sont dumpée directement dans un objet perms accessible directement)

Dans Django, la vue est l'équivalent en gros de l'action controller ailleurs, en tout cas c'est ce qu'il disent dans la doc

et ça devient classieux quand on commence à jouer avec les generic views \o/

Ce que je comprend pas là-dedans, c'est que, me semble-t-il, les opérations faites dans la BDD (insert update etc) doivent aussi etre déclenchés par la view... Hors là ça n'a plus rien a voir avec "quelles données sont présentées"...