Solution pour modifier un module existant ?
#9
Pour la documentation externe, ça serait effectivement mieux qu'elle existe aussi en anglais. C'est juste un manque de ressource si ce n'est pas le cas. Creme ne se veut pas franco-français, mais il faudrait un petit peu de travail pour qu'il soit international de base. C'est plus un problème de configuration qu'autre chose (et tout est faisable au pire par l'IHM), mais par exemple on met de base les taux de TVA français, pareil pour les statuts des entreprises (SARL etc...). Donc comme on ne fait pas encore l'effort de le faire connaître en dehors de la France, ce n'est pas le plus urgent.

contribute_to_model() n'est effectivement pas compatible avec les classes abstraites à cause de l'implémentation actuelle. Quand une classe abstraite est utilisée, django copie les champs dans la classe fille concrète, et l'information de 'dérivation' de classe est perdue (du coup ce n'est plus vraiment une dérivation au sens python) ; et quand contribute_to_model() fait son boulot c'est trop tard, la copie ayant déjà été faite. C'est un problème connu mais que je n'avais pas documenté ; je le ferai pour la version 1.4.2.

Quant au signal, je pensais au signal 'pre_save', qui mettrai une valeur à votre nombre entier dans le cas d'une création où la valeur du nombre n'aurait pas été précisée. Ça ne se substitue pas au travail que vous avez fait dans les formulaire (mais vous pouvez factoriser la fonction de génération du nombre par exemple), en revanche ça permet au code de ne pas planter lorsqu'une Opportunité n'est pas créée par vos formulaire. C'est pourquoi je disais que ce cas de figure ne vous générai peut-être pas en pratique, mais que le code était fragile dans l'absolu.
  Répondre


Messages dans ce sujet

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)