Add taxonomy-behavior to my behavior bundle

1

I have a bundle of behaviors (like IDublinCore) and would like to add a collective.taxonomy-behavior (collective.taxonomy.generated.university) to it. Now the taxonomy-behavior is generated at runtime with a Wrapper (see collective/taxonomy/generated.py#L43).

This is my bundle behavior.

@provider(IFormFieldProvider)
class IFHNWBasic(
    IBasic,
    ICategorization,
    IShortName,
    IExcludeFromNavigation,
    IVersionable,
    model.Schema,
):
    """Behavior with basic fields for FHNW"""

Has anybody an idea how I can achieve that?

As a workaround, I add it to the content type directly.

2

What we did to achieve this (edited to your universities case and assuming you have an addon package with a GS profile):

  1. create a folder profiles/default/taxonomies and add a file university.cfg

  2. The content of university.cfg can look like this:

[taxonomy]
name = universities
title = Universities
description = 
default_language = de
field_title = Universities
field_description =
taxonomy_fieldset = default  # or whatever you want
  1. create a universities.xml in the same folder with vdex data:
<?xml version="1.0" encoding="UTF-8"?>
<vdex language="en" orderSignificant="false" profileType="hierarchicalTokenTerms" xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imsvdex_v1p0 imsvdex_v1p0.xsd http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd">
  <vocabName>
    <langstring language="en">Universities</langstring>
  </vocabName>
  <vocabIdentifier>universities</vocabIdentifier>
  <term>
    <termIdentifier>main-term</termIdentifier>
    <caption>
      <langstring language="de">Hauptpunkt</langstring>
    </caption>
    <term>
      <termIdentifier>sub-term</termIdentifier>
      <caption>
        <langstring language="de">Unterpunkt</langstring>
      </caption>
    </term>
  </term>
</vdex>
  1. register your taxonomy behavior in the profiles/default/types/<yourtype>.xml file with:
  <property name="behaviors" purge="false">
    <element value="collective.taxonomy.generated.universities"/>
  </property>
  1. re-import your products profile and restart your instance ... the behavior should be available and registered to the contenttype.
3

Thx for your answer. Your suggestion is broadly what I am doing right now as a workaround.

Maybe I was not specific in my initial question: In the end I would like to have the universitiy-taxonomy-behavior as a part of IFHNWBasic. So when I assign IFHNWBasic to a contenttype the taxonomy-behavior is added as well to the contenttype.

I thought of something like this (but it's not working).

@provider(IFormFieldProvider)
class IFHNWBasic(
    IBasic,
    ICategorization,
    IShortName,
    IExcludeFromNavigation,
    IVersionable,
    Wrapper("university")
    model.Schema,
):
    """Behavior with basic fields for FHNW"""

It might be that this is not possible at all or very complex.

4

@adrianschulz You might be able to do something like this if you can arrange for it to happen late enough during startup that the ZCML configuration for collective.taxonomy is already active:

from collective.taxonomy.generated import universities
IFHNWBasic.__bases__ = IFHNWBasic.__bases__ + (universities,)

but this is kind of dark Python magic and I'm not sure I can anticipate possible side effects.

Generally I would discourage trying to bundle behaviors like this. It's not that hard to list them out separately in the type info XML, and it keeps things flexible if you need to change the order or replace one of them for a specific content type. I regret creating the IDublinCore bundle.

5

Oh sorry. Misunderstood this. Have you tried something like this?

from collective.taxonomy import generated

class IMySchema(generated.universities):
    """ """
6

Interesting. What's the reason you are discouraging bundle behaviors in general? Also the possible side effects?

7

This resulted in an AttributeError: AttributeError: 'NoneType' object has no attribute 'getSiteManager'

But since @davisagli raised concerns about it, I no longer follow that path. So my "workaround" will be the actual implementation. Thx anyway.

8

@adrianschulz I just found that it does not actually save much time, but makes things harder later when I want to change one of the behaviors.

1 Like