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/!