Appli YD – gestion des adhérents – héritage de classe (5/7)

Dans la 1ère version de l'appli, nous avons utilisé une variante d'héritage appelé "héritage de prototype" (à droite sur le schéma ci-dessous) qui consiste à dupliquer l'objet "hérité", en l'occurence "Partner".
Cela interdit ensuite de réutiliser les vues, wizard, workflow (etc ...) existants en lien avec l'objet d'origine.

Pour cette 2ème version de l'appli, nous utilisons la variante "héritage de classe".
Elle nous donnera la possibilité de réutiliser la vue "form" de l'objet Partner et ultérieurement, le wizard d'envoi de mail.
Nous nous attardons uniquement sur les fichiers "yd.py" et "view".

Dans le 1er fichier, seule la valeur de "_name" est modifiée.

impact dans fichier "yd.py"

Dans le 2ème fichier , 2 possibilités :
  1- Pas d'héritage de vue :
pour la vue "form", on modifie la valeur "model" avec "res.partner"  et on rend cette vue (eval ... priority...) plus prioritaire que la vue par défaut "view_partner_form"

extrait fichier "yd_view.xml"

   ... et pour la vue "tree"

extrait fichier "yd_view.xml"

  2- héritage de la vue "view_partner_form" :
avec modifications apportées pour supprimer des champs et onglets affichés dans l'objet de base et ajouter les champs spécifiques à "yd.member" (cf documentation officielle)

extrait fichier "yd_view.xml"

Personnellement dans notre cas, les modifications par rapport à la vue "view_partner_form" étant assez importantes, je préfère ne pas utiliser l'héritage de cette vue.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *