Closed (fixed)
Project:
Entity Construction Kit (ECK)
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Feb 2012 at 15:23 UTC
Updated:
5 Feb 2026 at 14:48 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
acrazyanimal commentedWhen 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 onEntity -> 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?
Comment #2
fmizzell commentedI 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.
Comment #3
acrazyanimal commentedI 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:
I can definitely see that we could abstract that process down to something like
That would be cool!!
Comment #5
fmizzell commentedExactly.. 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.
Comment #6
acrazyanimal commentedGot 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.
Comment #7
bforchhammer commentedI 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?
Comment #8
fmizzell commentedWell, 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.
Comment #9
bforchhammer commentedOkay, thanks for the explanation.
Comment #10
fmizzell commented@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.
Comment #11
acrazyanimal commentedcool!
Comment #12
fmizzell commentedComment #13
kasalla commentedI´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
Comment #19
colanComment #20
dieterholvoet commentedComment #22
dieterholvoet commented