Hey ! Youpi, encore un sujet à troll :D.
Bon sérieusement, j'ai une approche très proche de celle de Cyril
Mougel (yo bro!).
Toutes les données à présenter à la vue, on les encapsule dans des
blocs decent_exposure, certains même en appelant d'autres, exemple
classique :
class UsersController < ApplicationController
expose(:users)
expose(:user)
expose(:users_paginated) { users.page(params[:page]) }
# ...
Voilà, au final ça réduit fortement le nombre de before_filter. Ces
derniers ne sont plus utilisés pour initialiser des f*cking variables
globales mais principalement pour les redirections et la sécurité.
C'est magnifique.
Maintenant quand utiliser un Presenter ? C'est simple ! Exemple : tu
veux faire l'index du dashboard d'un user lorsqu'il se loggue.
Ce dashboard doit afficher une dizaine de stats sur le user, voir des
stats globales au site.
Plusieurs solutions :
* mettre les scopes et le traitement dans le contrôleur/vue : NON
(allo quoi !).
* mettre les scopes et le traitement dans le modèle User : oui mais
non. Pourquoi foutre 15 scopes et/ou méthodes dans ton User qui est un
modèle super critique si c'est juste pour afficher les données dans
une ou deux vues ?
* Mettre les scopes dans un module/concern et faire include/extend
dans User : super, t'as isolé tes scopes dans un autre fichier mais
ils se retrouvent quand même au final dans tous tes users sans
isolation. Faire include/extend au runtime dans le contrôleur :
bidouille Ruby moyen pour les perfs.
* Presenter : OUI. Une simple classe UserPresenter qui prend le user
en initialize et qui expose une stat par méthode. Et dans ton
contrôleur un joli : expose(:presenter) {
UserPresenter.new(current_user) }. Je pleure tellement c'est beau et
bien isolé et testable :').
Draper : personnellement j'aime pas trop. Il m'arrivait souvent de le
rajouter dans un projet pour au final l'utiliser très peu. Au pire,
faire une classe Presenter pour l'instance et/ou 2/3 helpers, personne
ne va mourir.
Les partiels : rien contre du moment que le partiel est utilisé avec
parcimonie en TOTALE isolation. Ce qui veut dire : pas de variables
globales dedans bien sûr et toutes les variables utilisées sont issues
du Hash de variables passé en paramètre, donc pas d'appel direct à des
variables helpers de contrôleurs (style current_user).
Le plus simple pour valider cela est d'écrire un test unitaire qui
render le partiel sans passer par la couche contrôleur juste avec un
passage de variables.
Helpers : idem partiels.
Nicolas.
2013/6/11 Guirec Corbel <[email protected]>:
> T'as raison sur le fait qu'il faut tester. C'est pour ça que je pose
> beaucoup de questions et met souvent en questions les pratiques que
> j'utilise. Je pense qu'on peut me donner la "palme d'or du gars le plus
> chiant du groupe parcequ'il pose toujours des questions".
>
> T'as raison, aussi, sur le fait que j'ai posé une question hyper vaste sans
> définir de problème précis.Je pense qu'il y a autant solutions qu'il y a de
> cas d'utilisation. Un truc qui ne suit pas les bonnes pratiques peut quand
> même être une bonne solution dans des cas particulier. J'ai récemment fait
> des modifs sur un site PHP super mal foutu avec du bordel partout. J'ai
> voulu repenser la structure et tout refaire alors que, finalement, mon
> client il veut juste une fonctionnalité simple et il se fout que son appli
> soit bien faite. J'aurai surement du faire un truc de porc parce-que le gars
> il aime bien joué lui même dans ces affaires et faire, lui même, des
> changements.
>
> Je penses, enfin, qu'il y a autant de solutions que de développeurs. Une
> bonne solution pour un développeur peut ne pas l'être pour un autre. Si,
> dans une entreprise, ils utilisent des outils drag and drop très peu souple,
> ça peut très bien faire l'affaire et ils seront content avec.
>
> La programmation est un sujet complexe où il n'existe pas une solution
> parfaite et une recette qui correspond à tout les problèmes. Malheureusement
> et heureusement à la fois.
>
>
> Le 11 juin 2013 13:07, Cyril Mougel <[email protected]> a écrit :
>
>>
>>
>>
>> 2013/6/11 Guirec Corbel <[email protected]>
>>>
>>> Merci pour vos avis. C'est une question que je pensais stupide mais je me
>>> rend compte que c'est quand même assez complexe. Je crois que ça viens en
>>> parti du fait qu'une vue n'est pas très objet.
>>
>>
>> Vive les FormObject de Django et le Google Summer Of Code => (
>> http://weblog.rubyonrails.org/2013/5/27/rails-google-summer-of-code-projects/
>> )
>>
>> C'est surtout que ta question posait tout et n'importe quoi. Presque du
>> niveau de Ubuntu ou Debian pour le serveur ? Tout marche. dépend du context.
>>
>>>
>>>
>>> Dans mon cas, je pense utiliser Drapper et les DecoratedFinder. Ça parait
>>> intéressant. En ce qui concerne Cells, je suis content de savoir que ça
>>> existe mais je crois que mes besoins sont suffisamment simple pour le
>>> moment. Je vais opter pour "KISS" et utiliser des partials pour les gros
>>> bout d'HTML.
>>
>>
>> Tu as oublié de mentionner :
>>
>> Objectify : https://github.com/bitlove/objectify
>> Focused_controller : https://github.com/jonleighton/focused_controller
>>
>>>
>>>
>>> Pour les helpers, je suis d'accord avec Olivier, il faut les utiliser
>>> quand ce n'est pas une fonction relié à un objet spécifique.
>>
>>
>> Les helpers aux chiottes.
>>
>>>
>>>
>>> Je vais devoir faire des recherches pour utiliser draper avec
>>> inherited_resources.
>>
>>
>> inherited_resources aux chiottes.
>>
>> Moi développeur, je dis que tous va aux chiottes dans les contextes ou ça
>> le mérite.
>> Moi développeur, je dis que decent_exposure > inherited_resources
>> Moi développeur, je pense que mon avis ne vaut rien et doit être mis aux
>> chiottes
>> Moi développeur, je pense problématique avant de penser solution.
>> Moi développeur, je change de gem tous les 6 mois.
>> Moi développeur, je test des patterns inutiles tous les 6 mois.
>> Moi développeur, je fais des Kata en utilisant les patterns pour
>> comprendre leurs but et surtout voir où c'est à mettre aux chiotte.
>> Moi développeur, je pense que mon code d'il y a 6 mois est de la merde
>> Moi développeur, je pense que ce que je dis surpasse tout alors que c'est
>> de la merde
>> Moi développeur, je ne jurerais que par une techno que je décrirais dans 6
>> mois.
>>
>> En gros, test test test test test et fait toi ton avis.
>>
>>
>> --
>> Cyril Mougel
>> http://blog.shingara.fr
>>
>> --
>> --
>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
>> Google Groups.
>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
>> [email protected]
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse
>> [email protected]
>> ---
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
>> Railsfrance.
>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
>> concernant, envoyez un e-mail à l'adresse
>> [email protected].
>> Pour plus d'options, visitez le site
>> https://groups.google.com/groups/opt_out .
>>
>>
>
>
> --
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> [email protected]
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> [email protected]
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> [email protected].
> Pour plus d'options, visitez le site
> https://groups.google.com/groups/opt_out .
>
>
--
Nicolas Blanco, Web developper
http://www.nicolasblanco.fr
Jabber/GoogleTalk : [email protected]
Twitter : http://twitter.com/slainer68
Github : http://github.com/slainer68
Skype : slainer68
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse [email protected].
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
