IRC logs of #tryton-fr for Monday, 2012-05-14

chat.freenode.net #tryton-fr log beginning Mon May 14 00:00:01 CEST 2012
2012-05-14 15:38 <rseon> re
2012-05-14 15:38 <rseon> je repose la question?
2012-05-14 15:39 <rseon> est-ce qu'on peut utiliser le contexte pour passer des informations pour savoir si on doit afficher un champ?
2012-05-14 15:40 <cedk> rseon: pour l'instant, le context des champs relations n'est passé que à l'appel de default_get
2012-05-14 15:42 <rseon> sachant que j'ai 10 variables possibles, mais je n'en affiche qu'une seule à l'utilisateur selon la valeur du parent, comment gérer?
2012-05-14 15:43 <cedk> rseon: utilise '_parent_xxx'
2012-05-14 15:44 <rseon> ok merci
2012-05-14 15:44 <rseon> je teste ça
2012-05-14 15:44 <cedk> rseon: il faut toujours privilégier les autres méthodes: domain, states avant d'avoir recourt au context
2012-05-14 15:45 <rseon> oui, oui, mais savoir dans quel cas utiliser l'un plutôt que l'autre, c'est pas encore tout à fait évident
2012-05-14 15:45 <rseon> :)
2012-05-14 18:16 <rseon> re
2012-05-14 18:16 <rseon> pour mon objet qui contient 10 One2Many
2012-05-14 18:17 <rseon> je voudrais initialiser automatiquement un des One2Many (car il ne peut y avoir qu'un seul One2Many de renseigné)
2012-05-14 18:17 <rseon> il y aurait un moyen simple?
2012-05-14 18:18 <cedk> rseon: l'initialiser avec quoi?
2012-05-14 18:18 <rseon> j'ai un objet A avec des liens A.B, A.C, A.D...
2012-05-14 18:19 <rseon> selon le cas je voudrais dès qu'on crée une instance de A
2012-05-14 18:19 <rseon> cela aille automatiquement créer A.B ou A.C ou A.D ...
2012-05-14 18:19 <rseon> on avait pensé à coder les méthodes default_B default_C
2012-05-14 18:20 <cedk> rseon: donc ce n'est pas un One2Many
2012-05-14 18:20 <rseon> si c'est un One2Many mais pardon, je veux dire un élément dans la liste
2012-05-14 18:21 <cedk> rseon: et bien tu peux utiliser default_B qui doit retourner une list de valeur de record
2012-05-14 18:21 <rseon> ok
2012-05-14 18:21 <rseon> c ce qu'on se disait
2012-05-14 18:22 <rseon> avec return [{}] pour initialiser un objet dans la liste c ca?
2012-05-14 18:23 <cedk> rseon: oui
2012-05-14 18:23 <rseon> mais comme on est très fainéant (ou plutôt on veut pas tout coder en dur)
2012-05-14 18:23 <rseon> on ne voudrait pas coder les méthodes mais les écrires à la volée
2012-05-14 18:24 <cedk> rseon: comprend pas
2012-05-14 18:25 <rseon> on a 10 liens
2012-05-14 18:25 <rseon> (et demain surement plus)
2012-05-14 18:26 <rseon> c'est pas top d'aller écrire 10 fois default_A : return [{}] default_B :...
2012-05-14 18:27 <rseon> sachant qu'il faudrait simplement aller boucler sur les variables de notre classe et aller coder la méthode defautlt
2012-05-14 18:27 <cedk> rseon: tu peux en faire une puis: default_B = default_A
2012-05-14 18:27 <rseon> oui enfin c pas exactement le même code non plus
2012-05-14 18:27 <cedk> rseon: tu peux aussi les ajouter dans le __init__
2012-05-14 18:27 <rseon> ah dans l'init
2012-05-14 18:27 <rseon> là ça m'interesse
2012-05-14 18:28 <rseon> on peut ajouter les fonctions dans l'init ou juste les modifiers?
2012-05-14 18:28 <cedk> rseon: dans le __init__
2012-05-14 18:29 <cedk> rseon: c'est pas la même chose que init
2012-05-14 18:29 <cedk> rseon: et oui on peux
2012-05-14 18:29 <rseon> ok ok
2012-05-14 18:29 <rseon> j'ai fait un raccourci pour taper sur l'irc
2012-05-14 18:29 <rseon> si t'as un exemple qq part, je veux bien
2012-05-14 18:30 <cedk> rseon: non, on evite de faire ça car le code est moins lisible
2012-05-14 18:31 <rseon> ça se discute
2012-05-14 18:31 <rseon> d'avoir 10 fois le même bout de code qu'il faut modifier à chaque fois qu'on ajoute une nouvelle dimension métier
2012-05-14 18:32 <rseon> c'est pas le top non plus
2012-05-14 18:32 <cedk> rseon: ben normallement, il doit pas changer
2012-05-14 18:33 <rseon> non, mais si on ajoute un nouvel aspect métier
2012-05-14 18:33 <rseon> il y aura plein de petit bout de code à écrire à gauche à droite
2012-05-14 18:33 <rseon> pour faire marcher cette nouvelle notion
2012-05-14 18:34 <rseon> ce qui est assez désagréable
2012-05-14 18:34 <rseon> alors que le principe de rendre ces mécaniques dynamiques c'est qu'une fois qu'elle fonctionne, on se concentre sur le métier
2012-05-14 18:36 <cedk> rseon: moi, j'ai l'impression que ça rend le code plus difficile à comprendre, or on passe 10 fois plus de temps à lire le code qu'à l'écrire
2012-05-14 18:38 <rseon> je sais bien que c'est le principe générale de python, mais je ne sais pas si ce principe s'applique dans ce cas
2012-05-14 18:38 <rseon> l'idée en verticalisant est tout de même d'encapsuler la partie métier pour ne pas à avoir à tout ré-écrire
2012-05-14 18:40 <rseon> il y a bcp de code métier (les règles métiers ne sont malheureusement pas toujours hyper logiques) et c'est bien de pouvoir s'appuyer sur un framework relativement souple

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!