XF 2.0 How to provide extensibility for other developers when extending core functions?

[CyberAP]

I am extending (i.e. replacing) fnAvatar() function. But I also want other developers to add new functionality there. What's the best way to do that? What steps should other developers take to add new functionality to my extended function?

 

[Mike]

It sort of depends what you mean. If you're extending the function (via a class extension), then other developer's extensions would apply as well. If you're replacing it, then that is likely to only allow one add-on's implementation to really be running at a time.

If you can explain what you mean in more detail, that may allow me to understand what you're after more.

 

[Liam W]

If you're changing it to change how avatars are generated or displayed, then the easiest thing to do would be to make it a complete override, but make sure that the class extension runs at the top of the structure, so all other add-on extensions build off yours.

When you create the extension, you can set the execution order - for your avatar one, set this to a really low value (I.E, 0).

Liam

 

[CyberAP]

It sort of depends what you mean. If you're extending the function (via a class extension), then other developer's extensions would apply as well. If you're replacing it, then that is likely to only allow one add-on's implementation to really be running at a time.

If you can explain what you mean in more detail, that may allow me to understand what you're after more.

I suppose the key difference between extension and replacement is the function return. I am returning a template object, instead of a string. So that means I am replacing that function completely. And my question is what is the best approach to provide extensibility for other developers in that way that they won't replace my function completely. How should I design my add-on to make it extensible and how should other developers use that properly (so that their code still works without my add-on)?

 

[Mike]

Well there isn't a ton you can do per se -- I mean, you are effectively just replacing our implementation, right? The only thing I'd recommend is that you return a string as that's what the method is expected to return (and the default version does).

Templater functions are reasonably low level, so it will always be difficult for multiple add-ons to change the same one in compatible ways, especially if you're overriding the main function itself (fnAvatar in this case), given that it's just returning HTML.

 

[CyberAP]

Well there isn't a ton you can do per se -- I mean, you are effectively just replacing our implementation, right? The only thing I'd recommend is that you return a string as that's what the method is expected to return (and the default version does).

Templater functions are reasonably low level, so it will always be difficult for multiple add-ons to change the same one in compatible ways, especially if you're overriding the main function itself (fnAvatar in this case), given that it's just returning HTML.

But that's the whole idea behind an add-on to extend current implementation of that functionality. How can I use renderTemplate() and return a string at the same time? Should I do it like this to preserve compatibility with other add-ons?

$renderedTemplate = $this->renderTemplate("public:avatar", $viewParams);

return strval($renderedTemplate);

 

[Chris D]

Your current method would already be cast to string eventually already but indeed making that the return value would be more expected.