26-05-2014, 17:28
Tout d'abord, merci pour vos réponses rapides et super détaillé !
Donc j'ai désactivé South pour l'instant. J'avais déjà essayé de remplacer le SET par un PROTECT (sans comprendre ce que je faisais) sans succès. Après j'avais pas essayé protect (en minuscule) ni en commentant la ligne dont il est question. Je verrai ça plus tard.
Je comprend mieux l'intérêt du champ référence maintenant. Mais une des raisons de la volonté de passer de SugarCRM à Crème CRM était l'absence de l'auto-incrémentation des numéros d'opportunités avec Sugar. Mais aussi parce qu'il est de plus en plus propriétaire.
Et merci, j'ai découvert l'existence de ces champs personnalisés, hooks et signaux pour Django. Quant à l'auto-incrémentation, j'ai fais comme vous m'avez conseillé, c'est-à-dire d'utiliser la fonction contribute_to_model. J'ai utilisé les hooks (add_post_init_callback).
Puis j'arrive presque au même résultat qu'avant mais de façon modulaire donc c'est super ! Voici du coup le code source du module. La seule chose qui manque est le positionnement du nouveau champ en-dessous du nom de l'opportunité. Car il est affiché plutôt en dernier. Ça doit pas être trop compliqué à mettre en oeuvre je pense.
J'ai des questions, sur le lien que tu m'as donné @genglert à propos de contribute_to_model(), tu parles de la disparition de cette fonction lorsque Crème utilisera la version 1.5 de Django, existera-t-il une fonction équivalente ? S'agit-il de ce monkey patching que tu as cité ? Aussi, existe-t-il un moyen de supprimer le champ référence de la classe model pour pas qu'il soit généré dans la table de la bdd ni affiché ? En fait je débute que depuis une semaine avec Python et Django donc pour ça que j'ai plein de questions qui peuvent porter sur Python et Django.
J'ai pour (mauvaise ?) habitude de faire les tests directement dans la fonction qui a besoin d'être testé. En effet tu as raison, il faudrait que je fasse les tests unitaires séparément. C'est pas comme si Django ne proposait rien de ce côté.
Également, je ne connais pas Mercurial, je ne connais que Git et SVN mais merci quand même du conseil pour "la queue de patch mercurial".
Bonne soirée !
EDIT : Pour votre information, j'ai tenté de récréer les fichiers de migrations comme il est bien expliqué ici avec la commande python2.7 manage.py schemamigration opportunity_number --initial. J'ai bien un fichier de migration qui a été créer. D'ailleurs ça a marché tandis que je n'ai que recloner le dépôt de Crème 1.4. Mais ce fichier ne contient pas plus que :
J'en ai donc déduis donc que les migrations sont incompatible avec contribute_to_model().
Je pense qu'il serait bien d'avoir une interface permettant de choisir quels champs (même natifs à Crème) afficher, déplacer. Et ajouter des propriétés aux champs personnalisés comme l'auto-incrémentation dans le cas d'un IntegerField.
Donc j'ai désactivé South pour l'instant. J'avais déjà essayé de remplacer le SET par un PROTECT (sans comprendre ce que je faisais) sans succès. Après j'avais pas essayé protect (en minuscule) ni en commentant la ligne dont il est question. Je verrai ça plus tard.
Je comprend mieux l'intérêt du champ référence maintenant. Mais une des raisons de la volonté de passer de SugarCRM à Crème CRM était l'absence de l'auto-incrémentation des numéros d'opportunités avec Sugar. Mais aussi parce qu'il est de plus en plus propriétaire.
Et merci, j'ai découvert l'existence de ces champs personnalisés, hooks et signaux pour Django. Quant à l'auto-incrémentation, j'ai fais comme vous m'avez conseillé, c'est-à-dire d'utiliser la fonction contribute_to_model. J'ai utilisé les hooks (add_post_init_callback).
Puis j'arrive presque au même résultat qu'avant mais de façon modulaire donc c'est super ! Voici du coup le code source du module. La seule chose qui manque est le positionnement du nouveau champ en-dessous du nom de l'opportunité. Car il est affiché plutôt en dernier. Ça doit pas être trop compliqué à mettre en oeuvre je pense.
J'ai des questions, sur le lien que tu m'as donné @genglert à propos de contribute_to_model(), tu parles de la disparition de cette fonction lorsque Crème utilisera la version 1.5 de Django, existera-t-il une fonction équivalente ? S'agit-il de ce monkey patching que tu as cité ? Aussi, existe-t-il un moyen de supprimer le champ référence de la classe model pour pas qu'il soit généré dans la table de la bdd ni affiché ? En fait je débute que depuis une semaine avec Python et Django donc pour ça que j'ai plein de questions qui peuvent porter sur Python et Django.
J'ai pour (mauvaise ?) habitude de faire les tests directement dans la fonction qui a besoin d'être testé. En effet tu as raison, il faudrait que je fasse les tests unitaires séparément. C'est pas comme si Django ne proposait rien de ce côté.
Également, je ne connais pas Mercurial, je ne connais que Git et SVN mais merci quand même du conseil pour "la queue de patch mercurial".
Bonne soirée !
EDIT : Pour votre information, j'ai tenté de récréer les fichiers de migrations comme il est bien expliqué ici avec la commande python2.7 manage.py schemamigration opportunity_number --initial. J'ai bien un fichier de migration qui a été créer. D'ailleurs ça a marché tandis que je n'ai que recloner le dépôt de Crème 1.4. Mais ce fichier ne contient pas plus que :
Code :
# -*- coding: utf-8 -*-
from south.utils import datetime_utils as datetime
from south.db import db
from south.v2 import SchemaMigration
from django.db import models
class Migration(SchemaMigration):
def forwards(self, orm):
pass
def backwards(self, orm):
pass
models = {
}
complete_apps = ['opportunity_number']J'en ai donc déduis donc que les migrations sont incompatible avec contribute_to_model().
Je pense qu'il serait bien d'avoir une interface permettant de choisir quels champs (même natifs à Crème) afficher, déplacer. Et ajouter des propriétés aux champs personnalisés comme l'auto-incrémentation dans le cas d'un IntegerField.