In my efforts to unify entities and fields #1412620: Make Fields Entities. I have gone through the mental exercise of trying to get all of the awesomeness of fields without fields. One of the challenges would be to replicate the behavior of bundles. I believe that some sort of Entity Type inheritance would solve that problem. Any thoughts?

CommentFileSizeAuthor
#6 eck-addField-1434238-2.patch3.77 KBacrazyanimal

Comments

acrazyanimal’s picture

When I first started working with Entities, this is exactly what I initially assumed they could do. I was disheartened when I found out there was only one level of inheritance Entity -> bundle. I had my heart set on Entity -> first level inherited entity -> second level inherited entity -> .. and so on. I also thought that an entity would surely inherit all of its "parents" fields. Again I was disappointed to find out only properties were inherited and entity types were not fieldable ... just plain old boring one dimensional properties!

Anyway, I agree in theory this would be awesome. Any ideas how it could be accomplished given the current framework provided in core and entity api?

fmizzell’s picture

I think the first step is to make field attachment as easy as possible for bundles. If we can abstract that process, then it would be easier for us to automate the generation of new entity types that inherit stuff from other entity types. Right now, I believe that creating entity type inheritance would be fairly simple, all we need is a way to store parent-children relationships which any tree structure can do. I think most of the complications come when we are dealing with bundles and fields.

@acrazyanimal have you given any more thought to this issue? I am hoping that in the end with can do stuff like this:

$bundle->addField('image');

And given that entity types are already fairly simple to create, simplifying bundle-field management could open a lot of doors, including complex inheritance hierarchies.

acrazyanimal’s picture

I haven't really given the field stuff much thought. At first reading your comment above I didn't think that there was much we could do to make it simpler then it already is, but scanning through the process again I am seeing possibilities.

So I guess there is quite a bit that could be abstracted into a single function for adding fields. However I think it would require that either a) we create a default abstraction function for each field type out there, or b) we add an api to ECK to allow field module developers to incorporate it into their modules.

For example with a complicated field like a taxonomy term reference you currently would have to do the following, assuming you are also creating a taxonomy:

  // Create a vocabulary for notification terms.
  $vocabulary = (object) array(
    'name' => t('Notification terms'),
    'description' => t('Use Notification terms to categorize content for instant notifications.'),
    'machine_name' => 'notifications_terms',
    'help' => t('Enter a comma-separated list of terms.'),
  );
  taxonomy_vocabulary_save($vocabulary);
  // Create a term reference field using the vocabulary.
  $field = array(
    'field_name' => 'field_' . $vocabulary->machine_name,
    'type' => 'taxonomy_term_reference',
    // Set cardinality to unlimited for tagging.
    'cardinality' => FIELD_CARDINALITY_UNLIMITED,
    'settings' => array(
      'allowed_values' => array(
        array(
          'vocabulary' => $vocabulary->machine_name,
          'parent' => 0,
        ),
      ),
    ),
  );
  field_create_field($field);
  // Add an instance of the term reference field to the article node type.
  $instance = array(
    'field_name' => 'field_' . $vocabulary->machine_name,
    'entity_type' => 'node',
    'label' => 'Notification terms',
    'bundle' => 'article',
    'description' => $vocabulary->help,
    'widget' => array(
      'type' => 'taxonomy_autocomplete',
      'weight' => -4,
    ),
    'display' => array(
      'default' => array(
        'type' => 'taxonomy_term_reference_link',
        'weight' => 10,
      ),
      'teaser' => array(
        'type' => 'taxonomy_term_reference_link',
        'weight' => 10,
      ),
    ),
  );
  field_create_instance($instance);

I can definitely see that we could abstract that process down to something like

  // Create a vocabulary for notification terms.
  $vocabulary = (object) array(
    'name' => t('Notification terms'),
    'description' => t('Use Notification terms to categorize content for instant notifications.'),
    'machine_name' => 'notifications_terms',
    'help' => t('Enter a comma-separated list of terms.'),
  );

  $options = array(
    'settings' => array(
      'allowed_values' => array(
        array(
          'vocabulary' => $vocabulary->machine_name,
          'parent' => 0,
        ),
      ),
    ),
  );
$bundle->addfield('taxonomy_term_reference', $options);

That would be cool!!

fmizzell’s picture

Exactly.. I haven't digged enough through the Field API system to know whether all field providers are required to give useful defaults for all their settings, but in the worst case we just need some metadata about the field like what pieces of information are required (the vocabulary machine name for the taxonomy_term field for example), etc.

acrazyanimal’s picture

Status: Active » Needs review
StatusFileSize
new3.77 KB

Got inspired this morning. Here is a start anyway. I just wrote it one off and did no testing whatsoever, I think its pretty complete in terms of what would be needed for a addField() function.

bforchhammer’s picture

I am currently trying to find out what the best way is to handle fields which are common to multiple bundles. I am wondering whether it might be possible to somehow specify a set of fields for an entity-type, and automatically have them added to all bundles of that entity type.

An example would be a "product" entity type and a "price" field, which is automatically added to all "product bundles".

Is this issue working towards this use case, or would that be something else?

fmizzell’s picture

Well, in Drupal most of our data is handled by fields, because it is the most powerful and user friendly way to do it at the moment. In reality, if you wanted a "field" to be a part of all of the entities of a given entity type, that information should be a "property" of the entity type. One of the goals of ECK is to make entity-type properties as powerful and user friendly as fields, but that goal is not directly related to this one.

To have a system in which entity types can inherit their structure from other entity types, we definitely need mechanisms that would allow us to duplicate structures with ease (like the patch added by acrazyanimal that makes it easier to add fields to a bundle). Those tools would make it easier to accomplish something like what you have described, but it is not the direct goal of the inheritance.

Another thing that might interest you is the idea of integrating ECK with the bundle copy module. #1361842: Add support for Bundle Copy, to allow for import/export.

bforchhammer’s picture

Okay, thanks for the explanation.

fmizzell’s picture

Status: Needs review » Needs work

@acrazyanimal I just tested the default (just giving the field type to the method) and everything seems to work pretty well. That is enough for me to commit the code. We will get more through testing as we continue toward the goal of this issue.

acrazyanimal’s picture

cool!

fmizzell’s picture

Status: Needs work » Active
kasalla’s picture

I´ve created a sandbox project with another approach.
There´s a modul "Bundle Inharitance". For this I created a tiny module.

Corresponding issue: https://drupal.org/node/2125065
Sandbox Project: https://drupal.org/sandbox/kasalla/2125031

  • Commit dc93b33 on 7.x-2.x, change_paths, own_permissions, 7.x-2.x-property-widgets, 7.x-3.x, entity_reference, 7.x-3.x-settings, 7.x-2.0.x, 7.x-2.1.x authored by acrazyanimal, committed by fmizzell:
    #1434238 AddField
    

  • Commit dc93b33 on 7.x-2.x, change_paths, own_permissions, 7.x-2.x-property-widgets, 7.x-3.x, entity_reference, 7.x-3.x-settings, 7.x-2.0.x, 7.x-2.1.x authored by acrazyanimal, committed by fmizzell:
    #1434238 AddField
    

colan’s picture

dieterholvoet’s picture

Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

dieterholvoet’s picture

Status: Fixed » Closed (fixed)