2016-03-04 3 views
0

Nous avons un type de contenu à base de Dextérité qui doit hériter d'une valeur par défaut de champ de son parent. Nous utilisons les éléments suivants:Comment tester un type de contenu avec un IContextAwareDefaultFactory

Dans le modèle:

<model xmlns="http://namespaces.plone.org/supermodel/schema" 
     xmlns:indexer="http://namespaces.plone.org/supermodel/indexer" 
     xmlns:form="http://namespaces.plone.org/supermodel/form"> 
    <schema> 
    ... 
    <field name="subjects" type="zope.schema.Tuple" indexer:searchable="true"> 
     ... 
     <defaultFactory>my.package.content.default_subjects</defaultFactory> 
     ... 
    </field> 
    </schema> 
</model> 

L'usine est déclarée comme ceci:

from zope.schema.interfaces import IContextAwareDefaultFactory 
... 
@provider(IContextAwareDefaultFactory) 
def default_subjects(context): 
    return getattr(context, 'subjects',()) 

Cela fonctionne bien lors de l'exécution d'une instance:

(Pdb) context 
<MyType at /Plone/folder> 
(Pdb) type(context) 
<type 'Acquisition.ImplicitAcquisitionWrapper'> 

Mais échoue lors de l'exécution de tests car le contexte n'est pas encapsulé:

(Pdb) context 
<MyType at test> 
(Pdb) type(context) 
<class 'my.package.content.MyType'> 

Comment puis-je résoudre ce problème?

+0

liée à peine: un [problème similaire] (https://github.com/collective/collective.newsticker/blob/master/src/collective/newsticker/controlpanel. py # L22-L30) Il y a quelque temps. – hvelarde

+0

Quel type de test utilisez-vous? Avez-vous eu un coup d'œil à https://github.com/plone/plone.dexterity/blob/master/plone/dexterity/tests/test_content.py#L492-L523 De cela, je suppose que cela dépend de votre schéma correctement chargé dans le fti. Peut-être que cela manque. Cela dépend de votre configuration de test. – do3cc

+0

ce sont les tests: https://github.com/plonegovbr/brasil.gov.agenda/blob/07b978038f5b0da18a66d449ec8f2b1c7e03d560/src/brasil/gov/agenda/tests/test_agendadiaria.py#L80-L98 – hvelarde

Répondre

1

Vous faites tout correctement. Lorsque dans le code que vous essayez d'accéder à des sujets comme ça:

>>> object.subjects 

Lorsque subjects n'a jamais été défini, la mise en œuvre de __getattr__ Dextérité commence son travail. Cette magie __getattr__ pour les attributs manquants est implémentée par Python. Il perd en quelque sorte l'emballage d'acquisition. Après avoir perdu l'emballage d'acquisition, ni aq_parent ni parent continuent de travailler. Dans mes tests, j'ai pu contourner en appelant

>>> object.__getattr__('subjects') 

Mais ce n'est pas satisfaisante. Du point de vue du code, vous ne rencontrez pas ce problème, car la vue n'accède pas du tout à l'attribut via object.subjects, de sorte que le contexte d'acquisition n'est jamais perdu.

Je vais terminer mon analyse, mais je l'ai noté mes conclusions dans un rapport de bogue plone.dexterity. Peut-être que vous voulez fournir un test minimal là: https://github.com/plone/plone.dexterity/issues/53

+0

merci, malheureusement je vais avoir à attendre plus de financement dans ce projet; Je vais ajouter une référence à cela. – hvelarde