Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I would like to insert an edit link as a views field to my entity view, much like I can with nodes. Is this possible?
Comment | File | Size | Author |
---|---|---|---|
#21 | 1333870-21.entity.views-entity-link-field.patch | 3.28 KB | joachim |
| |||
#15 | 1333870.entity.views-link.patch | 3.21 KB | joachim |
Comments
Comment #1
fagoYep, sounds good. However, the problem is we don't generally know the edit / delete location, though some entities provide an "edit-url" property and token.
So first, we need establish and document a way for entities to declare their edit / delete location.
Comment #2
mstrelan CreditAttribution: mstrelan commentedAlso, some entity types may not have an edit url, for example Field Collection. The Bean module provides a method
editURL()
, perhaps this could exist in the Entity class and simply return FALSE.Comment #3
fagoThe entity class is optional, so it's not good to rely upon it for this.
I think we should make this even more general, so that any entity-type can specify their edit-url location.
Comment #4
bojanz CreditAttribution: bojanz commentedI like the "operations" way of doing things (through contextual links).
I have "bojan/%bojan" as the path, handler gets all contextual links, pulling "bojan/%bojan/edit", "bojan/%bojan/delete" or whatever exists and is accessable.
That's how Commerce and many contribs around it approach the problem, seems more flexible than just talking about edit urls or delete urls.
Comment #5
fagoMakes sense to me, though I fear that pattern doesn't apply in all cases.
Do you support possible other operations too? Are you assuming edit/delete is there for any entity?
Doing an operations URL pattern sounds like a good idea though. E.g. an 'operation url callback' + entity_operation_url() function? Which operations should we support, just hard-coded 'edit', 'delete' ?
Comment #6
bojanz CreditAttribution: bojanz commentedYou are just saying "get me contextual links for provided $url". Whether the module provided "edit", "delete", "call fago", or something else entirely is up to them :)
No assumptions.
Comment #7
fagooh, I see. Well, that should do it for Views but for modules it's probably more useful to have access to edit/deletion URLs? E.g. you could generate a "edit referenced entity" link for an entity formatter. If I only get the whole operations, I cannot control link texts.. :/
Comment #8
MichelleI found this discussion because I was curious if how Bean does it was a standard and searched on it. I'm going to follow this in Artesian, too, since it makes sense, but will also keep an eye on this issue in case you go a different direction.
Michelle
Comment #9
fagoI guess we should just add some general "links" views integration, which we can auto-generate for entities provided with the entity API.
->
View link, Edit link and Delete link - as Views does for node links. Then, those plugins should probably provide the URLs as replacement pattern.
Comment #10
fmizzell CreditAttribution: fmizzell commentededmund.kwok recently wrote this functionality for ECK: #1424738: Views integration: Add view, edit, delete link. ECK stores the information about the operations url in the entity_info array, so it can be easily manipulated and accessible. If the urls are specified in the plugins, from what I understand, the urls will be static at that point, right?. I suggest using the properties array as the middle man to store this information. Since not all url properties are operations, maybe we can set a flag or something to let us know that that url is an operation also.
Comment #11
joachim CreditAttribution: joachim commentedThe problem is that functions like entity_access() and entity_uri() expect a full $entity to be passed to them. Unlike the handlers for node link and node edit link, we can't just know that the right path is 'node/NID' and 'node/NID/edit'.
That's doable for a Views handler, but it's a drain on performance.
Comment #12
alexweber CreditAttribution: alexweber commentedThe problem is that when trying to implement this manually using hook_views_data() and implementing a custom handler it breaks the Entity API views integration (not sure why at this point).
EDIT: Ok so apprently Entity API implements hook_views_data() on our behalf (somehow), so if we want to add additional stuff we need to use hook_views_data_alter(), this way we don't overwrite what Entity API generously provides.
Comment #13
alexweber CreditAttribution: alexweber commentedI've updated the handbook to reflect this, I lost a good half hour scratching my head because of this :)
Comment #14
AaronBaumanThe way ECK does this, as fmizzel mentioned above, is to alter the entity_info and add crud links, like so:
This seems like a useful thing to be implemented by all instances of hook_entity_info() (or hook_entity_info_alter()).
Where it's relevant, [crud] might even include "clone", "revert", or whatever other operations necessary.
This also addresses joachim's concern in comment #11: using the structure above, from ECK, we wouldn't need a fully-loaded entity, just the entity id.
Comment #15
joachim CreditAttribution: joachim commentedHere's a patch that does the 'view' link part at least -- that's fairly easy to do.
As pointed out above, to support 'edit' and 'delete' links we'll need more entity type metadata.
Comment #16
alexweber CreditAttribution: alexweber commentedHey joachim, I've actually implemented this myself for a couple custom entities and the solution I came up with is pretty generic:
The above also works with delete as well, comments before I roll a patch?
Comment #17
AaronBaumanalex: the problem is relying on the convention that appending "/edit" will take you to the entity's edit form.
though this is true most of the time, it's only a convention and cannot be relied upon exclusively.
testbot is not cooperating, but this patch implements my suggestion from comment #14:
#1309332-10: Expose field-collection operational links in views
Comment #18
alexweber CreditAttribution: alexweber commented@aaronbauman, ohh gotcha ok yeah that makes sense... It's a shame that despite being the convention it is up to the module developer when implementing his hook_menu() so yeah, bummer... maybe we can add extra "edit" and "delete" suffix keys to the hook_entity_info() and we can assume its "entitypath/suffix" from here on out?
Comment #19
JeebsUK CreditAttribution: JeebsUK commentedWas there ever any consensus reached on this? I've just run into this exact scenario and seen this issue hasn't had any updates for nearly two years.
Comment #20
joachim CreditAttribution: joachim commentedhttps://drupal.org/project/entity_operations has this feature, precisely because it allows entity types to declare a 'base path' and then operation path elements, along the lines of 'node/X/edit', 'node/X/delete' and so on.
/shameless promotion ;)
Comment #21
joachim CreditAttribution: joachim commentedSmall update to the patch:
- added a file docblock
- fixed mentions of 'node' in the views field handler comments
Comment #22
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 3 year old patch in #21 to entity.info, entity.views.inc and entity_views_handler_field_entity_link.inc applied cleanly to the latest entity 7.x-1.x-dev and would still be a great feature to have in 7.x.