1. #1
    Sencha User
    Join Date
    Nov 2007
    Location
    London, UK
    Posts
    583
    Vote Rating
    0
    mabello is on a distinguished road

      0  

    Default Plugin architecture: unload method for a plugin

    Plugin architecture: unload method for a plugin


    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
    PHP Code:
    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 
    0len this.plugins.lengthleni++){
                            
    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

  2. #2
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    16
    jack.slocum will become famous soon enough

      0  

    Default


    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.
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  3. #3
    Sencha User
    Join Date
    Nov 2007
    Location
    London, UK
    Posts
    583
    Vote Rating
    0
    mabello is on a distinguished road

      0  

    Default


    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!

Thread Participants: 1

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar