Ok en tout cas un grand merci bestmomo.

Je te suis depuis un moment sur ton site et laravel.fr et maintenant sur le SdZ.

Tu auras vraiment permis à la communauté française de pouvoir rentrer dans ce fabuleux framework.

Personnellement, j'ai commencé avec Symfony et il est vrai que Laravel fais aussi partie des grands aujourd'hui

Bonne continuation ;) 

Je plussoie Echyzen Merci bestmomo !

Bonjour,

après avoir fini le chapitre 1, je m'attaque aux bases de données. 

Et j'ai une question. 

Dans la partie "injection de dépendances", on crée la classe PhotoGestion pour gérer (dans ce cas) la sauvegarde de la photo.

Est-ce envisageable de mettre cette gestion dans le modèle directement ? Donc faire un mix entre la classe Email, et la classe EmailRepository ? Ainsi, on injecterai directement la classe Email dans le controller ? Ou je suis à l'ouest, et j'ai pas tout compris ? 

Merci d'avance

@mrjenkins

Bonjour,

On peut tout envisager du moment que ça reste simple et qu'on s'y retrouve facilement. La classe Model a pour but d'offrir une représentation sous forme objet d'une table d'une base de données. La question est : "Est-ce une bonne idée de lui donner aussi pour tâche la gestion des données correspondantes ?". Une saine approche est d'affecter une seule tâche à une classe, là il semblerait qu'on mette sur les épaules du modèle plusieurs tâches. Un repository a justement pour mission unique la gestion des données.

Ceci dit tout dépend de la dimension d'une application et de ses évolutions probables. Cette répartition entre plusieurs classes peut sembler inutile pour une petite application (ce qui est évidemment le cas pour l'exemple du cours), par contre elle devient pertinente dès que le code commence à prendre du volume. Au final c'est une question de choix. Dans le cours je me suis attaché à présenter l'approche qui me paraît la meilleure avec des tâches bien identifiées et réparties, après chacun est libre d'opter pour une autre formule, il n'y a pas de règle universelle en la matière, il y a juste des patrons de conceptions qui constituent de fait une référence.

Cordialement,

Maurice

Merci pour cette réponse claire et détaillée.

Dans ce cas, je me permets de donner un exemple plus complexe (un cas de mon 1er site web, développé en php prodécural... ^^)

Supposons une table "carte" qui contient, entre autres, des données A, B, C et D. J'aurai donc une classe modèle Carte. Si je dois traiter ces données (pour l'exemple, on va dire A+B+C*D) dans une méthode calculate() celle-ci serait donc mieux dans le Repository ? Sachant que pour une carte, on a une dizaine d'action possible.

C'est bien ça ?

Je dirais que ce n'est pas vraiment la tâche du repository sauf si on s'en sort directement avec du SQL parce qu'on combine des données dans une table. Si ce n'est pas le cas il vaut mieux créer un service dédié avec une classe Calcul par exemple. Le repository a normalement pour seule tâche de gérer le stockage des données (mémorisation, test de présence, récupération, etc...), on parle aussi de persistance des données, on l'utilise comme si les données étaient directement en mémoire, à lui de se débrouiller pour faire toutes les manipulations nécessaires.

Un bon exemple de repository dans Laravel est Illuminate\Config\Repository.php.

Si l'anglais ne te fait pas peur cet article est intéressant tant du point de vue du contenu que de la discussion qui le suit.

-
Edité par bestmomo 22 mai 2015 à 16:38:20

Hum ok, mais dans ce cas, où mettre ce genre de méthodes (là c'était un calcul simple sur une seule instance, on pourrait envisager ce genre de calcul sur plusieurs instances) ? 

Un autre exemple pourrait être celui des combattants : $joueur1->attaque($joueur2). 

Cette méthode attaque va comparer différents attributs des joueurs (points de vie, attaque ...). Où devrait-on traiter ce genre de process (dans l'idéal, puisqu'au final, on peut le mettre un peu où on veut avec Laravel ) ? 

Le plus simple est de créer un service dans app\Services, soit une classe, soit un fichier de fonctions à charger. Il est aussi possible d'utiliser des commandes dans app\Commands. Si ça prend de l'ampleur alors il faut passer directement à un package. En fait il y a de multiples solutions avec Laravel c'est vrai .

Ok c'est donc des notions que je n'ai pas encore :) 

En avançant dans le cours, j'essaye déjà de me projeter dans mon futur projet

Merci beaucoup pour tout ! 

Il ne faut pas oublier qu'il s'agit dans le fond uniquement de PHP. La plus-value réside dans le conteneur de dépendances et l'autoload. Il est ainsi facile de charger et utiliser une classe, où qu'elle se trouve, en prenant la précaution de l'indiquer à Laravel.

Exact. Mais j'ai encore un peu de mal avec l'injection de dépendances justement. 

Mais en effet, le tout c'est de s'y retrouver et de ne pas donner trop de tâches différentes à une classe :) 

J'ai relu la fin de la partie 1 et le début de la partie 2. Je pense avoir saisi mon incompréhension. Merci de me confirmer ou non

Dans la partie 1, on crée une classe de gestion pour sauver les photos. Dans ce cas, on crée une classe à part pour le traitement. 

Dans la partie 2, on crée une classe "repository" car son but est la persistance, donc liée directement à la base de données (ce qui n'était pas le cas dans la partie 1).

Donc pour faire un traitement non lié à la DB → classe de gestion dans un dossier lambda.

Traitement DB → classe repository dans le dossier Repositories.

J'ai bon ? J'aimerai vraiment comprendre ce point avant de continuer :) 

Merci !!

La différence ne tient pas au fait d'être ou non lié à une base de données. Dans l'activité de la partie 1 les données sont mémorisées dans des fichiers, alors que dans la seconde il s'agit d'une base. Dans les deux cas on peut utiliser un repository pour la gestion.

Si je n'ai pas nommé "repository" la classe de la première activité c'est que sa tâche n'est pas aussi clairement identifiée. Elle gère totalement les données, jusqu'à s'occuper directement des fichiers à créer. On va dire que j'ai un peu mélangé les genres pour simplifier. Alors que dans la deuxième activité on a une séparation entre les modèles et le repository.

Mais bon on pourrait longtemps discuter et il n'aurait finalement pas été totalement déplacé de nommer aussi "repository" la classe de la première activité. L'essentiel est de comprendre le principe de séparation des tâches.

Oki doki :) 

Je pense que c'est clair

Encore merci pour les explications et la patience ! 

@bestmomo , @Keylekan

Merci pour votre aide, j'ai bien fait un 777 sur le dossier storage et vendor.

Et ensuite comme Keylekan, un AllowOverrideAll dans le fichier apache2.conf, et maintenant l'application fonctionne.

Je continue le cours !

Bonjour, 

pour revenir sur la séparation des tâches. Supposons que la table users possède en plus un champ date "last_login". 

Ce champ est mis à jour à chaque login (de type post, et si validé). D'ailleurs, pour ce faire, j'ai overridé la méthode postLogin (de AuthenticatesAndRegistersUsers) dans mon AuthController, est-ce la bonne méthode ? 

Pour mettre à jour ce champ, j'ai créé un repository qui contient une fonction updateLastLogin(User $user). Dans mon authController, j'appelle cette méthode avec $request->user() comme paramètre. Mes questions : 

- est-ce que cette méthode est correcte ? 

- n'est-il pas préférable de mettre cette méthode dans App\User, et ainsi faire un simple $request->user()->updateLastLogin() ? 

Merci d'avance

@mrjenkins

Bonjour,

Pour déclencher une tâche chaque fois qu'il y a un login la façon la plus élégante est d'utiliser un événement, et ça évite de surcharger le contrôleur. Laravel déclenche un événement pour un certain nombre d'actions importantes, et le login en fait partie. Il suffit donc d'écouter cet événement et d'activer par exemple une commande, puisque c'est une tâche élémentaire. C'est une bonne occasion pour voir comment Laravel gère les événements et les commandes puisque je n'en parle pas dans le cours .

Dans mon exemple d'application j'utilise cet événement, non pas pour mettre la base à jour mais pour changer le statut de l'utilisateur en session, mais ça donne une façon d'organiser la chose. A noter que j'ai utilisé un raccourci par rapport au codage préconisé dans la documentation parce que je n'ai pas utilisé d'event handler.

Cordialement.

Merci beaucoup, je ne connaissais pas cet aspect de Laravel. 

En allant dans la doc (en fr ) le 1er exemple est mon cas :) 

Bon je vais devoir l'agrémenter, mais ça a l'air de répondre tout à fait à ce que je cherche.

Attention, la documentation en français concerne Laravel 4, il y a quelques différences même si les fondamentaux sont identiques.

Oui je m'en suis rendu compte au final :D 

De mon côté, je n'ai pas utilisé d'Event (puisque le framework fire un event au login = auth.login). J'ai juste créé un handler, et renseigné le lien dans l'EventServiceProvider. Mais le fait de pouvoir créer soi même des events peut être utile. 

Encore merci. 

Bonjour :) 

J'aimerai customiser un peu la vue de register. Et à la place du champ "name", j'aimerai mettre "username". 

Donc, dans ma table users, j'ai bien mis username, ainsi que dans ma vue. 

Mais quand je post mon register, j'ai cette erreur :

Whoops! There were some problems with your input.

• Le champ Nom est obligatoire.

Et pas moyen de trouver où est configuré ce validator.. Un petit indice ? 

Merci

Bonjour

La validation pour les users est dans app/Services/Registrar.php.

Nickel merci beaucoup.

Bonsoir, 

j'ai une question sur les relations entre 2 tables. Comment faire pour gérer 2 foreign keys qui pointent vers un même champs d'une même table ? Exemple :

un modèle 'Message privé', qui contient 2 attributs 'auteur_id' et 'destinataire_id'. Ceux-ci étant des ID du modèle User. 

L'idéal serait d'avoir accès aux données des 2 users depuis les MP, et d'avoir l'ensemble des messages reçus d'un user.

Merci

Bonsoir,

Il suffit de prévoir les deux relations :

class Message extends Model {

    public function auteur()
    {
        return $this->belongsTo('App\User', 'auteur_id);
    }

    public function destinataire()
    {
        return $this->belongsTo('App\User', 'destinataire_id');
    }

}

-
Edité par bestmomo 28 mai 2015 à 21:59:51

Edit : Message inutile du coup !

-
Edité par Crazyweedz 28 mai 2015 à 22:07:03

Bonsoir,

en expérimentant les repositories, je me demandais quelle était la meilleure pratique pour les méthodes qui agissent sur un objet. Vaut-il mieux passer l'id de l'objet en paramètre de la méthode, ou l'objet complet ? 

Par exemple, pour un UserRepository, pour les méthodes de type update, delete.. on passe l'id, et on récupère le user dans la méthode, ou on passe directement le user pour agir dessus ?

En vous remerciant d'avance

@mrjenkins

Bonsoir,

Je pars du principe qu'un contrôleur doit en savoir le moins possible sur le traitement nécessaire. Donc le contrôleur se dit : "je récupère l'id d'un utilisateur dans l'url, de par la constitution de la requête on veut un update, donc je demande au repository de mettre à jour l'utilisateur qui a cet id et je lui envoie les données nécessaires qui sont dans la requête".

Mais après il faut raisonner selon le contexte avec comme guides la simplicité, la maintenabilité et la testabilité. Certains diront que pour une application toute simple un repository constitue du code inutile. Tout ça peut se discuter longuement . Il est juste important de comprendre comment tout ça s'articule, ce qu'il est possible de faire, et d'opter pour un codage qui nous convient.

Bonjour,

noté, merci beaucoup :) 

@mrjenkins,

Pour un peu enrichir la réponse il y a aussi la possibilité de lier un modèle à une route. Dans ce cas évidemment on se retrouve directement avec le modèle dans le contrôleur et on le transmet au repository.