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
rseonre15:38
rseonje repose la question?15:38
rseonest-ce qu'on peut utiliser le contexte pour passer des informations pour savoir si on doit afficher un champ?15:39
cedkrseon: pour l'instant, le context des champs relations n'est passé que à l'appel de default_get15:40
rseonsachant que j'ai 10 variables possibles, mais je n'en affiche qu'une seule à l'utilisateur selon la valeur du parent, comment gérer?15:42
cedkrseon: utilise '_parent_xxx'15:43
rseonok merci15:44
rseonje teste ça15:44
cedkrseon: il faut toujours privilégier les autres méthodes: domain, states avant d'avoir recourt au context15:44
rseonoui, oui, mais savoir dans quel cas utiliser l'un plutôt que l'autre, c'est pas encore tout à fait évident15:45
rseon:)15:45
rseonre18:16
rseonpour mon objet qui contient 10 One2Many18:16
rseonje voudrais initialiser automatiquement un des One2Many (car il ne peut y avoir qu'un seul One2Many de renseigné)18:17
rseonil y aurait un moyen simple?18:17
cedkrseon: l'initialiser avec quoi?18:18
rseonj'ai un objet A avec des liens A.B, A.C, A.D...18:18
rseonselon le cas je voudrais dès qu'on crée une instance de A18:19
rseoncela aille automatiquement créer A.B ou A.C ou A.D ...18:19
rseonon avait pensé à coder les méthodes default_B default_C18:19
cedkrseon: donc ce n'est pas un One2Many18:20
rseonsi c'est un One2Many mais pardon, je veux dire un élément dans la liste18:20
cedkrseon: et bien tu peux utiliser default_B qui doit retourner une list de valeur de record18:21
rseonok18:21
rseonc ce qu'on se disait18:21
rseonavec return [{}] pour initialiser un objet dans la liste c ca?18:22
cedkrseon: oui18:23
rseonmais comme on est très fainéant (ou plutôt on veut pas tout coder en dur)18:23
rseonon ne voudrait pas coder les méthodes mais les écrires à la volée18:23
cedkrseon: comprend pas18:24
rseonon a 10 liens18:25
rseon(et demain surement plus)18:25
rseonc'est pas top d'aller écrire 10 fois default_A : return [{}] default_B :...18:26
rseonsachant qu'il faudrait simplement aller boucler sur les variables de notre classe et aller coder la méthode defautlt18:27
cedkrseon: tu peux en faire une puis: default_B = default_A18:27
rseonoui enfin c pas exactement le même code non plus18:27
cedkrseon: tu peux aussi les ajouter dans le __init__18:27
rseonah dans l'init18:27
rseonlà ça m'interesse18:27
rseonon peut ajouter les fonctions dans l'init ou juste les modifiers?18:28
cedkrseon: dans le __init__18:28
cedkrseon: c'est pas la même chose que init18:29
cedkrseon: et oui on peux18:29
rseonok ok18:29
rseonj'ai fait un raccourci pour taper sur l'irc18:29
rseonsi t'as un exemple qq part, je veux bien18:29
cedkrseon: non, on evite de faire ça car le code est moins lisible18:30
rseonça se discute18:31
rseond'avoir 10 fois le même bout de code qu'il faut modifier à chaque fois qu'on ajoute une nouvelle dimension métier18:31
rseonc'est pas le top non plus18:32
cedkrseon: ben normallement, il doit pas changer18:32
rseonnon, mais si on ajoute un nouvel aspect métier18:33
rseonil y aura plein de petit bout de code à écrire à gauche à droite18:33
rseonpour faire marcher cette nouvelle notion18:33
rseonce qui est assez désagréable18:34
rseonalors que le principe de rendre ces mécaniques dynamiques c'est qu'une fois qu'elle fonctionne, on se concentre sur le métier18:34
cedkrseon: 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'écrire18:36
rseonje sais bien que c'est le principe générale de python, mais je ne sais pas si ce principe s'applique dans ce cas18:38
rseonl'idée en verticalisant est tout de même d'encapsuler la partie métier pour ne pas à avoir à tout ré-écrire18:38
rseonil 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 souple18:40

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!