3

In Making use of the admin UI, Step 3 - Implement the entity adding/editing form, it says that you need to implement "a" form with the ENTITY_TYPE_form() signature for add/edit/clone operations...

However the wiki page is not specific in regards to whether you should implement one or two forms. I explain - the example creates two "entities": a "regular" entity, and a "bundle" entity. The example then implements ENTITY_TYPE_form() for the "bundle" kind of entity ONLY.

In attempt two answer the question: "Should I implement one or two forms?" I looked at the source code of both the Model and the Profile2 modules. The source of my confusion is that the Profile2 module implements only one form - like in the example - for the "bundle" kind of entity. But on the other hand the Model module implements two forms: one for the "regular" entity, and another one for the "bundle" entity. Why? What's the correct use case? What's the difference between the two implementations? What additional ability does implementing the "regular" entity form give us, if any?

1
  • 1
    I think that it may be because Profile2 allows users to edit ONLY the profile bundle, and for the user the "regular" or "base" entity is invisible - whereas with the Model module users are allowed to edit the "model" bundle, as well as interact with the "base" entity. Commented Aug 16, 2013 at 23:17

2 Answers 2

0

You're essentially correct I think. You can write a hard-coded Entity or make something more flexible supporting bundles (hard coded bundles, or say user-defined bundles like the Profile2 module) .... it can get as complicated as you want! :D

Have you seen this sandbox released a few days ago showing the mimimum for 1 hardcoded entity using Drupal core API and then an Entity supporting bundles via the EntityAPI.

https://drupal.org/sandbox/AlexanderAllen/2062531

This module aims to provide a developer friendly, ready to use, barebones implementation of a custom Entity.

The master branch provides a single, hardcoded entity (bundles are not supported), lacks entity revisioning support, and the only CRUD operation supported is save(). At a total of 16 functions, 4 files, one class and one method - the mater branch is recommended for understanding what is the bare minimum needed to create a custom Entity by code - using the Drupal core Entity API only.

The bundles branch adds bundle and automatic CRUD support with the help of the Entity API contributed module.

This module was inspired by the Profile2 and Model modules. This module is simpler than Model in that it uses the default UI and Entity controllers. If you're already comfortable with Entities, you should refer to the Model module instead for help with creating custom UI and Entity controllers.

0

There are actually two entities in play in both examples. Model has two entity types, model and model_type. Profile2 also has two, profile2 and profile2_type.

The different bundle types are defined by the respective bundle entities.

In your example, the profile2 module only defines a form to create/edit bundles for the profile2 entity.

The model module in your example, defines a form for adding/editing both the bundle types for the entity, as well as the entity itself.

To answer your question. You will want one _form hook for each entity you want to be able to edit/insert. If you want to be able to manipulate the bundle entity and the entity using forms, you will need to form hooks.

If you only want a form for one of them, you'll need only one form hook.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.