XF 2.2 Code Event listeners

Kirby

Well-known member
According to [urlhttps://xenforo.com/community/help/resource-standards/]resource standards rule #20[/url] code event listeners should be used instead of full class extensions wheever possible.

However, this rule does not stete exactly how they should be used.

For example, if an Add-on requires modifying Post and Attachment structures, several approaches could be used:
  1. One code event listener on entity_structure without a hint
    PHP:
    public static function entityStructure(\XF\Mvc\Entity\Manager $em, \XF\Mvc\Entity\Structure &$structure)
    {
        switch ($structure->shortName)
        {
            case 'XF:Post':
                // do smth.
                break;
            case 'XF:Attachment':
                // do smth.
                break;
        }
    }
  2. Two code event listeners, each with an appropriate hint but still just one callback like in 1)
  3. Two code event listeners, each with an appropriate hint and a distinct callback
    PHP:
    public static function entityStructureXFPost(\XF\Mvc\Entity\Manager $em, \XF\Mvc\Entity\Structure &$structure)
    {
                // do smth.
    }
    
    public static function entityStructureXFAttachment(\XF\Mvc\Entity\Manager $em, \XF\Mvc\Entity\Structure &$structure)
    {
                // do smth.
    }
Which one is preferred / recommended @ChrisD ?
 

Chris D

XenForo developer
Staff member
2 or 3.

Using hints is always better as it reduces the amount of times the code is called somewhat dramatically.

I’d usually prefer 3 but 2 is valid especially if there is any code shared between the listeners.
 

Kirby

Well-known member
Thanks for the feedback @Chris D :)

One further question though:
If option 3) is generally the preferred option (assuming that there is no shared code), is there also a recommended/preferred naming scheme for the methods?
 

Xon

Well-known member
I vastly prefer class extensions as it allows me to type-hint the extended class which is really helpful for preventing errors when using a field

But it is also very rare I'm not injecting additional code via class extensions.
 
Top