Useless app question

[SneakyDave]

I haven't jumped into too much of xenForo development yet, but for a completely useless add-on, what would be the general theory about creating something that would give a new member an award if they registered with the literal "dave" in their name?

Is there a user-registration code event to listen for, or is that too granular? I assume that a person would just take a look at the award generation code and copy that into their add-on for when the condition arises at registration? Would the "alert" to the user happen automatically, or would that need to be created?

I'm not interested in creating a specialized view, just the general flow of things that would need to happen.

 

[Jeremy]

If you take a look at my Stop Forum Spam add on, it has the same philosophy. You create an event lister that 'extends' the Register class, and obviously create that class.

You're class will have the definition of:

StopForumSpam_ControllerPublic_Register extends XFCP_StopForumSpam_ControllerPublic_Register

In it, you want to extend the actionRegister() function, you would want to do the checking and find out if it's located in there, do data handling, then call return parent::actionRegister(); at the end to return it back to XenForo.

 

[dmnkhhn]

Probably wrong but:

Extending is done via this EventListener (Register.php)

<?php
class MyAddon_EventListener_Register
{
    public static function listen($class, array &$extend)
    {
        if ($class == 'XenForo_ControllerPublic_Register')
        {
            $extend[] = 'MyAddon_ControllerPublic_Register';
        }
    }
}

... and a new Code Event Listener that
listens on event load_class_controller and executes the above method (MyAddon_ControllerPublic_Register::listen) - right?

 

[Jeremy]

dmnkhhn, that seems to be correct, and MyAddon_ControllerPublic_Register has to extend an imaginary class (XFCP_MyAddon_ControllerPublic_Register).

 

[Deceptor]

dmnkhhn, that seems to be correct, and MyAddon_ControllerPublic_Register has to extend an imaginary class (XFCP_MyAddon_ControllerPublic_Register).

That's right, XenForo will automatically proxy the classes from all event listeners that extend default classes, which is why the fake extension class is required. For example (if I'm wrong please let me know):

Assume you have 2 modifications extending the XenForo_ControllerPublic_Register class, called:
- AddonOne_ControllerPublic_Register
- AddonTwo_ControllerPublic_Register

Both of these classes will extend non-existant classes, which is XFCP_{classname), the XFCP I presume standing for XenForo Class Proxy. As you know when a class is initialised it'll inherit the parent class (in this case none-existant classes), so XenForo will map the Class Proxy to the correct parent based on execution order - so when processed it would end up being:

AddonTwo_ControllerPublic_Register extends AddonOne_ControllerPublic_Register extends XenForo_ControllerPublic_Register

Then when XF wants to initialise the controller for Register, it'll come back with the class name AddonTwo_ControllerPublic_Register. Fairly nice system, and the class proxy only requires some very tiny evals which is negligible towards load You can check all this out in the method "resolveDynamicClass" located within: ./library/XenForo/Application.php

 

[dmnkhhn]

Thanks for the explanation, very helpful.