Plugin architecture: unload method for a plugin

[mabello]

I really like the plugin architecture implemented in Ext, it is very powerful and very neat.

I was wondering if the public interface of a "plugin" must have an "unload" method, called by the Component class during the destroy moment of the component lifecycle
This is the modified destroy function for the Component class

destroy : function(){
        if(this.fireEvent("beforedestroy", this) !== false){
            this.beforeDestroy();
            if(this.rendered){
                this.el.removeAllListeners();
                this.el.remove();
                if(this.actionMode == "container"){
                    this.container.remove();
                }
            }
            //---ADD
            if(this.plugins){
                if(Ext.isArray(this.plugins)){
                    for(var i = 0, len = this.plugins.length; i < len; i++){
                        this.plugins[i].unload();
                    }
                }
                else {
                    this.plugins.unload();
                }
            }
            this.plugins = null;
            //---ADD
            this.onDestroy();
            Ext.ComponentMgr.unregister(this);
            this.fireEvent("destroy", this);
            this.purgeListeners();
        }
    } 

I know that the plugin can attach to the destroy event, but in my opinion it makes much more sense if a plugin has to implement the unload method.
So a developer is forced to remember to "clean" what has to be cleaned in the plugin instance, and the Component class can clear and delete the reference to the plugins instances and make everything "garbage collectable".

The problem could be that all the plugins created so far has to implement the unload method, so mantain the compatibility for all the existent plugins...but that's another story

[jack.slocum]

If a plugin needs destruction, it should use the destroy (or beforedestroy) events. This way it can plug in destruction at the point where it needs it, not at a predetermined point. I can't see any benefit in doing it another way. That, in a nutshell, is how plugins were intended to work - use events or methods which are already publicly available.

[mabello]

Dear Jack,
Thanks for your kind answer.

This way it can plug in destruction at the point where it needs it, not at a predetermined point

If you create a plugin for a component , I think it's good idea that a plugin follows the lifecycle of the component that use the plugin instance, if not, I do not think it's a plugin, that's my point of view about a general plugin architecture view, and because of that I had suggested an unload method for the plugin. Besides, you have a "symmetry" with the init method, and I like it, but it's only a question of personal taste I would say

The "unload" method has the benefit to "force" a developer to clear references etc inside the plugin and to follow the component lifecycle; as I said in my post, I know you can attach to the destroy or beforedestroy event, and actually you can achieve the same with the events, and it's seems of course more flexible than my suggestion, but I bet that every plugins created for Ext components so far are following the component lifecycle so why not an unload method...besides some of the existent plugins needs destruction but developers can easly "forget" about that...CheckColumn plugin is one of the examples...

Honestly I see problems for all the existent plugins implementation introducing the mandatory unload method in the plugin interface, and as you I do not see any spectacular benefict from the unload method of course.

But at least, the component class has to remove the reference to the plugins inside the property plugins and set this.plugins to null in the destroy lifecycle moment.

Of course, it's not a critique of the existent plugin architecture, I love it and besides it works great , it's only my point of view.
Thanks for your great work with ExtJS!