XF 2.2 Extend entity/threadfield

[Robert9]

<?php

namespace Xencafe\...\XF\Entity;

class ThreadField extends XFCP_ThreadField
{
    public static function getStructure(Structure $structure)
    {
        self::setupDefaultStructure(
            $structure,
            'xf_thread_field',
            'XF:ThreadField',
            [
                'groups' => ['before', 'after', 'thread_status','header'],
                'has_user_group_editable' => true,
                'has_wrapper_template' => true,
            ]
        );

        $structure->relations['ForumFields'] = [
            'entity' => 'XF:ForumField',
            'type' => self::TO_MANY,
            'conditions' => 'field_id'
        ];

        return $structure;
    }
}

To extend groups and having a new position for my fields, i have solved it by
replace the complete $structure, but there is a shorter way, please?

 

[Jeremy P]

You can go to the definition of \XF\Entity\AbstractField::setupDefaultStructure to see what it does. In this case, the groups option is setting the allowedValues on the display_group column. You can add your new display group to the array like any ordinary PHP array:

$structure->columns['display_group']['allowedValues'][] = 'whatever';

 

[Robert9]

Then I allow it for all custom_fields like this? Also for the RM for example?

 

[Jeremy P]

Any entity calling that method with groups can be appended this way (including the pertinent XFRM ones).

 

[Robert9]

Yes, and that's ok because we need to parts to add more values; so I can do it for threads plus your suggestion, but not for RM.
Thank you.

 

[Jeremy P]

I'm not sure what you mean by parts so maybe I am misunderstanding, but you can certainly do the same thing for XFRM in exactly the same way by extending the pertinent classes there if you wish.

 

[Robert9]

You need two parts to make it work, this is the thread specific part:

<?php

namespace Xencafe\ExtThread\XF\Repository;

class ThreadField extends XFCP_ThreadField
{
    public function getDisplayGroups()
    {
        return [
            'before' => \XF::phrase('before_message'),
            'after' => \XF::phrase('after_message'),
            'thread_status' => \XF::phrase('thread_status_block'),
            'header' => \XF::phrase('xc_ext_thread_header'),
        ];
    }
}

This is the part to allow the value, not specific and used by all thread, user, resource ... that use the function

$structure->columns['display_group']['allowedValues'][] = 'header';

Result: I have it for threads, but not for RM or others, everything is fine. Thank you.

 

[Jeremy P]

You need two parts to make it work, this is the thread specific part:

When extending existing methods, you should always call the parent class or you risk breaking other add-ons which extend the same method:

public function getDisplayGroups()
{
    $displayGroups = parent::getDisplayGroups();

    $displayGroups['header'] = \XF::phrase('xc_ext_thread_header');

    return $displayGroups;
}

This is the part to allow the value, not specific and used by all thread, user, resource ... that use the function

While the same line will work for the XFRM, this part is still specific to threads since you are only extending the thread field entity.

 

[Robert9]

Thank you very much; so the solution to add a another place for our thread custom_fields is

namespace Name\Addon\XF\Repository;

class ThreadField extends XFCP_ThreadField
{

    public function getDisplayGroups()
    {
        $displayGroups = parent::getDisplayGroups();
    
        $displayGroups['name_new_place'] = \XF::phrase('name_addon_name_new_place');
    
        return $displayGroups;
    }
    
}

and

namespace Name\Addon\XF\Entity;

use XF\Mvc\Entity\Structure;

class ThreadField extends XFCP_ThreadField
{
    
    public static function getStructure(Structure $structure)
    {

        $structure = parent::getStructure($structure);

        $structure->columns['display_group']['allowedValues'][] = 'name_new_place';

        return $structure;
    }
        
}

 

[Kirby]

namespace Name\Addon\XF\Entity;

use XF\Mvc\Entity\Structure;

class ThreadField extends XFCP_ThreadField
{
   
    public static function getStructure(Structure $structure)
    {

        $structure = parent::getStructure($structure);

        $structure->columns['display_group']['allowedValues'][] = 'name_new_place';

        return $structure;
    }
       
}

You shouldn't do this as per Resource Standards Rule # 20

 

[Robert9]

Where a specific code event exists, a listener should be created to utilise it rather than a full class extension.

Your comment wants to explain why we use the result from #9?
Or wants to tell that i should use a listener instead entity?

 

[Kirby]

Or wants to tell that i should use a listener instead entity?

Exactly (as explained in the rule).

 

[Robert9]

What is the difference?
And why i should use a listener, when i need that entity-file anyway?

 

[Kirby]

What is the difference?

A full class extension deepens class hierarchy, this should be avoided if only things that can be handled via listeners need to be done.
(Like modifying structure as shown in your code).

And why i should use a listener, when i need that entity-file anyway?

The code you posted was a full class extension that did nothing but extend the structure - this should be avoided as per resource standards rule # 20.
If your extension class also has other code (like custom methods or extended methods besides preSave/postSave/etc.). it would be fine.