Add EntityTrait::getDisplayField() or EntityTrait::getTable()

[kevinquinnyo]

This is a (multiple allowed):

• bug

• enhancement

• feature-discussion (RFC)

• CakePHP Version: 3.4.9

• Platform and Target: n/a

What you did

Tried to get the displayField directly from an Entity.

What happened

Unable to do so directly from the entity.

What you expected to happen

I think it would be a useful feature to pass down the primaryKey and displayField to the entity. Perhaps the EntityTrait could have a getDisplayField() and getPrimaryKey() ?

Since these methods already exist on the table, maybe it would make more since to allow you to get the full table class directly from an entity? That way I could do something like: echo $entity->getTable()->getDisplayField()

I'm not sure if that would be the better approach or not.

I'm also not sure if that should return the actual property name, or if it should actually internally run $this->get($this->_displayField) and actually return the value.

I think if it just returned the actual displayField name, that might be ok because it would be used something like this:

$displayField = $entity->getDisplayField();
echo $entity->get($displayField); // or simply echo $entity->$displayField;

Maybe there's a better idea for that?

I hope that makes sense. Basically this would be useful if you know you have entities but don't necessarily know which entities (perhaps passed to a template from a global search controller) and you want to display each one's displayField without having to go and ask each one's Table classes.

I'm not sure how hard it would be to implement something like this or really how to go about it. I assume the Marshaler would be responsible for passing it to new Entity classes?

[markstory]

What kind of situations do you find yourself needing these methods? How would the meta data get set when someone used new Article()?

[kevinquinnyo]

How would the meta data get set when someone used new Article()?

I hadn't considered that. In fact I don't think I've ever instantiated an entity without using the table, ie - $this->Articles->newEntity().

What kind of situations do you find yourself needing these methods?

Only once so far to be honest. Parsing the results that a very basic SearchController passes to the the view. Depending on the context of what was requested, different tables are loaded, and a viewVariable results is passed down. To format the results, I wanted to generate URLs and use each one's displayField as the "anchor text" of the URL. For some of them it's the name property, for others it's id, and for others it might be say, username.

So when iterating disparate entities in the results, I thought it would be handy if i could just do <?= $this->Html->link($entity->displayField(), [// ...]) >? (or something like that)

Does that make sense?

[kevinquinnyo]

For what it's worth, a colleague of mine pointed out that the idea I mentioned of having $entity->getTable() is probably not a good idea because it would encourage or easily allow the bad practice of doing business logic down in the view, like running queries. I tend to agree with that.

[kevinquinnyo]

I think it's also worth questioning whether this is something that should be provided by the framework, when I could easily implement it by extending the Entity class on my own with something like this if I wanted:

<?php
namespace App\Model;

use Cake\ORM\Entity as BaseEntity;
use Cake\ORM\TableRegistry;

class Entity extends BaseEntity
{
    public function __construct(array $properties = [], array $options = [])
    {
        parent::__construct($properties, $options);
    }

    public function getDisplayField()
    {
        $displayField = TableRegistry::get($this->getSource())->getDisplayField();
        
        return $this->$displayField;
    }
}

[sdustinh]

I have found myself wishing I had access to the primary key and display field settings from the entity on the view layer surprisingly often. Some specific use cases would be generic page header elements, bread crumbs, navigation, or form buttons. I have always turned to sane defaults to cover the majority of situations but it would be nice if the primary key / display field were included. It would potentially cut down on my inflector use, too. 👍 I like this.

[sdustinh]

In regards to new Article(), it could be handled like getSource. If the source isn't available it could just return null.

[markstory]

Given that entities have getSource() could applications that need to access id/display fields use the source to access the table and get the required metadata?

[ADmad]

They sure can. I don't like the idea of having direct methods on entity to get table meta data.

[kevinquinnyo]

They sure can. I don't like the idea of having direct methods on entity to get table meta data.

why?

[ADmad]

Because they are properties of model not entity.

For the particular example you gave regarding search results, you can use accessors and add _getDisplayField() to your entities which returns display field value and use $entity->displayField in your view.

[kevinquinnyo]

Ok that makes sense.

What you describe is basically what I was thinking about doing but it made me wonder if it should be an 'out of the box' feature since it seems useful to me.

Since that's a very easy way for me to achieve the same effect, this can probably be closed. I'll leave it open in case anyone else wants to chime in though

[markstory]

Closing as I think the accessor approach suggested by @ADmad is a great way to address this in applications that need it.