Solution pour modifier un module existant ?
#8
J'ai juste eu besoin de savoir quand elles étaient appelés les fonctions callbacks. Ce qui était expliqué sur la doc. Par contre il vaudrait mieux la faire en anglais, non ?

J'ai réorganisés les imports et j'ai mis la déclaration des callbacks dans le creme_core_register. En fait j'avais cru lire que tu m'avais conseillé creme_config_register. Je me suis mélangé avec la documentation. Donc oui c'est uniquement par chance que ça fonctionne. ^^

je crois avoir compris le problème dans le cas où une classe modèle Opportunity est instancié. Mais bon de toute façon je n'autorise pas les valeurs nulles. Mais après, c'est vrai que c'est mieux si la fonctionnalité d'auto-incrément est également présente sans créer de formulaire. Donc du coup je vais utiliser les signaux pour l'auto-incrémentation.

Je vais faire ça aujourd'hui.

EDIT : En fait quand j'utilise le le signal post_init() sur la classe modèle Opportunity, le numéro est bien mis à jour quand il y a création d'une opportunité mais aussi quand je veux afficher la vue de la liste des opportunités. Du coup, toutes les opportunités affichent (car ce n'est pas le cas dans la bdd) le dernier numéro présent dans la table + 1. Donc le signal est émit même quand il affiche la liste. J'ai essayé de connecter le signal et un slot dans la fonction callback (add_post_init_callback). Je pensais aussi déconnecter le signal et le slot à chaque fois que le traitement à été fait (autoincrémentation). Mais la fonction callback utilisé n'est exécuté qu'après que la classe modèle associé au formulaire est instancié. Ça aurait été possible avec une fonction callback exécuté avant genre add_pre_init_callback() mais on perd l'intérêt d'avoir voulu délégué l’auto-incrémentation à la classe modèle...

EDIT2 : Je travaille là sur un nouveau module de recherche par tag et j'ai comme l'impression que contribute_to_model ne marche pas sur les classes abstraites. La recherche par tag nécessite que j'ajoute ce champ à toutes les entités de crème. Donc j'ai vu que les champs en communs sont déclarés dans CremeAbstractEntity (classe parente de CremeEntity) dans creme_core/models/base. Quand je contribue à CremeEntity, la création des fichiers de migration et la migration marchent (pas le reste mais bon c'est normal). Mais quand je contribue à CremeAbstractEntity, là où je devrais normalement, j'ai le droit à de la part de South "nothing seems to have changed". Après le problème vient peut-être de South, je vais le désactiver pour voir ce que ça donne...

EDIT3: Après désactivation, le champ n'est même pas crée ni sa colonne dans la table creme_core_cremeentity. Sinon toujours avec South désactivé, la colonne se crée uniquement quand je contribue à CremeEntity.

La seule solution qui à l'air de bien fonctionné c'est de coder directement dans le module creme_core...

Également, je viens de me rendre compte qu'aujourd'hui qu'il existe un paramètre facultatif pour supprimer certains champs avec contribute_to_model(). J'aurais pu l'utiliser pour le champ "reference" pour le module ajoutant les numéros d'opportunités.

Oui, je détaille tous ce que je fais, mon feedback ne pourra que vous être utile pour que vous soyez conscient de ce qui a besoin d'être amélioré même si l'erreur vient de moi. Smile
  Répondre


Messages dans ce sujet

Atteindre :


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