Background

OG's new branch have entity reference fields, and those fields reference a single entity and all or several bundles of that entity type. This means that I can have better metadata property, as I know the entity type, and the bundles.

In og_entity_property_info() I now have something like this:

// Add OG membership per field in a bundle.
foreach (og_get_group_audience_fields($entity_type, $bundle) as $field_name => $label) {
  $params = array('@label' => $label);
  $field_info = field_info_field($field_name);
  $info[$entity_type]['bundles'][$bundle]['properties'][$field_name . ':og_membership'] = array(
    'label' => t('OG membership from field @label', $params),
    'type' => 'list<og_membership>',
    // The bundle in this context means the OG membership type.
    'bundle' => $field_info['settings']['handler_settings']['membership_type'],
    'description' => t('A list of all OG memberships registered in field @label.', $params),
    'getter callback' => 'og_get_field_og_membership_properties',
  );
}

This allows me to do something like this (assuming I have a field called og_group_ref, to get the memberships associated with that field.
$wrapper->og_group_ref:og_membership->value();

Problem

I would like to define a properties for the OG membership called "group", that will bring me the group (e.g. the node). Since I know the field I am in, I would like to define this property using the exact type (i.e. "node", not "entity").

How can I achieve that?

CommentFileSizeAuthor
#1 entity_bundle_details.patch815 bytesfago
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

Title: How to define a sub-property » Allow bundles to re-define existing properties
Category: support » task
Status: Active » Needs review
FileSize
815 bytes

You can add special properties only by bundle - just add it to the group-contents hook_entity_property_info() below the appropriate bundle key.

However, I assume you have the same property defined as generic entity without the bundles, what the wrappers are not prepared for right now.

The fix should be relatively simple - I think the attached patch should do it (not tested).

amitaibu’s picture

> However, I assume you have the same property defined as generic entity without the bundles

No, I will not use the generic entity, as in the above case I know to which entity/ bundles the field is attached to, and I know to which group/ group-bundles it references.

fago’s picture

That sound's great. However, which kind of property info do you declare for the group on entity-type level where you probably don't know the bundle?

My impression was you'd have to declare the property generally there (e.g. 'entity') and then on the bundle level you declare it more detailed, i.e. specify a fixed entity type or bundle. For that, you'd need #1.

Or how would you plan it?

amitaibu’s picture

> My impression was you'd have to declare the property generally there (e.g. 'entity') and then on the bundle level you declare it more detailed, i.e. specify a fixed entity type or bundle. For that, you'd need #1.

Exactly.

We have two different properties $wrapper->og_membership which we have no info about, so we have to use the generic 'entity' type. And we have $wrapper->field_name:og_membership which gets all the OG membership registered under the field name, in related to that entity. So, since we have the field name, we can know the group-type and group-bundle.

However, I'm still not sure on how to declare this. I've tried
$info[$entity_type]['bundles'][$bundle]['properties'][$field_name . ':og_membership']['properties']['group']['type'] = $group_type; , but it's not the right way?

btw, I've just realized I can already do things like $wrapper->field_name:og_membership[0]->group->status->value() (where group is defined as a generic entity). So I guess the above change is mostly important to Rules users, where they define a strict entity type for their rules.

fago’s picture

We have two different properties $wrapper->og_membership which we have no info about, so we have to use the generic 'entity' type. And we have $wrapper->field_name:og_membership which gets all the OG membership registered under the field name, in related to that entity. So, since we have the field name, we can know the group-type and group-bundle.

I see, that's fine. For that you won't need #1 as it are two different properties.

btw, I've just realized I can already do things like $wrapper->field_name:og_membership[0]->group->status->value() (where group is defined as a generic entity). So I guess the above change is mostly important to Rules users, where they define a strict entity type for their rules.

Yes, you always have access to fields on run-time. Annotating the metadata though helps other modules to know what to expect later on though, like Rules yes.

$info[$entity_type]['bundles'][$bundle]['properties'][$field_name . ':og_membership']['properties']['group']['type'] = $group_type; , but it's not the right way?

No. ;)

First off, please don't use the colon as it would break tokens and Rules. Property names are only allowed to contain lower-case alphanumeric characters + the underscore.

Secondly, there is no such properties key defined in 'property info'. There is 'property info', but that's for 'struct' property-types only. As said, you cannot do that beside annotating the property for the given entity type / bundle. Thus, just annotate it for the og-membership bundle to which the field points. That said, is the group type known per membership bundle in advance?

For having the general membership pointing to a group of type 'entity' and to be able to override it with a concrete entity-type per membership-bundle you'd need the patch from #1 . With the patch, the per-bundle definition overwrites the entity-type definition of the property.

fago’s picture

Status: Needs review » Fixed

ok, I've committed #1.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.