Since each entity type has an "entity class" defined, there is absolutely no reason to use any controller other than EntityAPIController.
You can specify defaults and buildContent in the entity class as well.
See my commerce_offer sandbox for an example (all the defaults are just class properties of the entity class).

After this is done you can remove the 'creation callback', as well as functions for creating, saving, deleting entities, and rely on the ones provided by Entity API (entity_create, entity_save, entity_delete)

Comments

ronald_istos’s picture

ronald_istos commented

I see you point - probably right. I think there is some confusion between what the entity class itself and the entity controller should be doing and want to think about it a bit more.

bojanz’s picture

bojanz commented

Yes, it is still fuzzy. I made the changes to commerce_offer after talking with fago about it and us coming to the conclusion about the way of providing defaults (#1109828: Document how defaults for entity properties should be provided).
As for buildContent, that method can just be copied verbatim, and Entity API will be just as happy.

fago’s picture

fago
Primary language German
Location Vienna
commented

Yep, I'd suggest not overriding the controller class if possible. That way it could be exchanged easily, in theory. (e.g. to use another storage system).

awochna’s picture

awochna commented

I agree that it can make it more confusing. However, I can also see the value in showing newer people that you can override these things if necessary. I think that the documentation could be used to emphasize that you don't need overrides.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
Status: Active » Needs work

Could you perhaps create a patch to show us what's really needed and what is not?
The optional overrides might be added as comment? (to comment out like overrides in template.php?)