Drupal Association members fund grants that make connections all over the world.
Part of meta-issue
This patch is being developed in the CMI sandbox: config-list-1781372-tim branch
Obviously we have to remove that dependency for Views to go into core, but more than that, this would be useful for all configuration entities, e.g., the vocabulary listing at
We've rewritten Views to use that already, and the above screenshot show the new code, not CTools :)
EntityListControllerInterface and a
list controller class key for
With the current patch (which removes non-essential functionality and defers it to the followup issues below), you can implement the list for a given
my_entity entity type provided by
my_module with the folllowing steps:
$return['my_entity']['list controller class']in the
The class must implement
EntityListControllerInterface. For a
theme_table()listing of entities similar to the Views screenshot at right or the current
admin/structure/taxonomypage, use or extend
EntityListController. For configuration entities, use or extend
Create a page callback that calls
entity_list_controller('my_entity')and renders the result.
- Define a path for the listing in the
- (optional) Define a
MENU_LOCAL_ACTIONmenu item with a page callback that adds entities of the given type.
Seefor followup discussion on how the path definitions for CRUD operations might be simplified.
#20: The possible operations for an entity are actually bound to the entity, not the list [controller]. It would make much more sense to have that as a concept and method on the
Entityclass. The per-entity operations can be re-used in many other situations. See .
#20: We need to figure out how to dynamically enhance the output/operations for
BundleConfigEntityobjects; i.e., Configurables that represent bundles for another entity type (e.g.,
NodeTypeentities are the bundles for
Node). These entity types typically have additional "manage fields" and "manage display" links in their operations. The
'fieldable'property in entity info cannot be leveraged, because that property is not set for the entity we're listing, but instead is a property of the "other" entity type that ours provides bundles for. Since it becomes more and more clear that we'll need a
BundleConfigEntityInterfacefor these kind of entities, we could check the implemented interface though.
The current config entity listing pages in HEAD only output the label of the Configurable, but not the machine name. The node/content type listing page is the only exception; it outputs
@label <small>(Machine name: @id)</small>in the Label column. Exposing the machine name is definitely beneficial for users that are seeking for a particular one, but an entire (table) column looks and feels too dominant.
The operations links (e.g.
delete, etc.) are related to each individual entity and defined in the list controller class for rendering, but in response to feedback (#16), the listing path itself and the path to add a new entity of the given type (which are related to the entity type rather than specific entities) are set separately in
hook_menu(). As a result, the "Add" link is not displayed within the empty text of the listing table, because this text cannot be set through
hook_menu(). should provide a more complete solution. See #102.
- was postponed on this issue.
FAILED: [[SimpleTest]]: [MySQL] 41,968 pass(es), 1 fail(s), and 1 exception(s). View
PASSED: [[SimpleTest]]: [MySQL] 41,974 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 41,964 pass(es). View