Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
entity system
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
13 Aug 2013 at 20:31 UTC
Updated:
29 Jul 2014 at 22:46 UTC
Jump to comment: Most recent file
Updated: Comment #0
In many implementations of list controllers, the buildHeader() and buildRow() go to ridiculous lengths to reuse the parent implementation.
Take this example from \Drupal\user\RoleListController:
/**
* {@inheritdoc}
*/
public function buildHeader() {
$row = parent::buildHeader();
$row['label'] = t('Name');
unset($row['id']);
$row['weight'] = t('Weight');
return $row;
}
This is only slightly better in buildRow(), this from ImageStyleListController:
/**
* {@inheritdoc}
*/
public function buildRow(EntityInterface $entity) {
$row = parent::buildRow($entity);
unset($row['id']);
return $row;
}
This makes any upstream changes harder to make.
Make it easier to reuse the generic buildHeader() and buildRow() implementation by only returning 'operation'.
This is the only key that is used across the board, and it is always last.
This way you could build your row and then do
return $row + parent::buildRow();
without fear of clashes or need to unset anything.
Write a patch
N/A
No true API change, but expectations need to be adjusted
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | list-2064557-12.patch | 28.1 KB | tim.plunkett |
| #10 | interdiff.txt | 514 bytes | tim.plunkett |
| #10 | list-2064557-10.patch | 28.2 KB | tim.plunkett |
| #8 | list-2064557-8.patch | 28.19 KB | tim.plunkett |
| #8 | interdiff.txt | 2.05 KB | tim.plunkett |
Comments
Comment #1
tim.plunkettYes, this requires the list controllers to do
$row['label'] = String::checkPlain($entity->label());, but it prevents us from having to do stuff like this to preserve ordering:#1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController) will be able to just add modify buildRow and buildHeader, and it will Just Work™.
Comment #2
andypostSuppose better get rid of local variables in favour of plain array()
why not
return array('operations' => t('Operations'))same
Comment #3
tim.plunkettCore does both in different places. Definitely on multiple lines either way, for adding stuff later.
I don't care either way, I'm going to wait for the test results and more reviews before changing.
Comment #5
tim.plunkettI'm going to leave it as is, no reason to make the patch bigger.
Comment #6
tim.plunkettMissed a spot.
Since this now covers the intention of #2027117: Always use parent::buildRow($entity) in EntityListController, I'm marking that as a duplicate (even though it has a completely opposite approach).
Comment #8
tim.plunkettFixes for contact and picture.
Comment #9
andypostI think better replace title with label in doc-block too
So all entities must implement their own list controller?
Suppose this should be:
Comment #10
tim.plunkett1) Sure thing
2) Yes. I see no real way around it. Also the only 3 that didn't have them were two test entity types and Picture Mapping, which isn't actually used in core... So in reality everyone was overriding this anyway.
3) No, the array structure here is pretty complex already, I don't think we should overcomplicate it. Plus it's the Views UI, which was very very specific in D7 already.
Comment #11
andypostMakes sense, so let's get commiter's feedback (supposing patch is green)
Comment #12
tim.plunkettRerolled for the Plugin/Core/Entity move
Comment #13
alexpottCommitted d663924 and pushed to 8.x. Thanks!