We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 7923
    • 4,213 Posts
    hello, I’m just starting with this MODExt / Ext, so sorry if this is too obvious... I’ve built most of this based on looking at how Quip and MODx manager does things, but now I hit a problem that I can’t seem to find answer to..

    I have the following windows set up:
    yagUpload.window.CreateContainer = function(config) {
    	config = config || {};
    	Ext.applyIf(config,{
    		title: _('yagupload.create_new_container')
            ,id: 'yagupload-window-create-container'
    		,width: 600
    		,url: yagUpload.config.connector_url
    		,action: 'mgr/container/create'
    		,fields: [{
                xtype: 'textfield'
                ,name: 'name'
                ,id: 'yagupload-createcontainer-name'
                ,fieldLabel: _('yagupload.name')
                ,width: 300
    		},{
                xtype: 'textfield'
                ,name: 'path'
                ,id: 'yagupload-createcontainer-path'
                ,fieldLabel: _('yagupload.path')
                ,width: 300
            }]
            ,keys: []
    	});
    	yagUpload.window.CreateContainer.superclass.constructor.call(this,config);
    };
    Ext.extend(yagUpload.window.CreateContainer,MODx.Window);
    Ext.reg('yagupload-window-create-container',yagUpload.window.CreateContainer);
    
    yagUpload.window.UpdateContainer = function(config) {
    	config = config || {};
    	Ext.applyIf(config,{
    		title: _('yagupload.update_container')
            ,id: 'yagupload-window-update-container'
    		,width: 600
    		,url: yagUpload.config.connector_url
    		,action: 'mgr/container/update'
    		,fields: [{
                xtype: 'hidden'
                ,name: 'id'
                ,id: 'yagupload-updatecontainer-id'
            },{
                xtype: 'textfield'
                ,name: 'name'
                ,id: 'yagupload-updatecontainer-name'
                ,fieldLabel: _('yagupload.name')
                ,width: 300
    		},{
                xtype: 'textfield'
                ,name: 'path'
                ,id: 'yagupload-updatecontainer-path'
                ,fieldLabel: _('yagupload.path')
                ,width: 300
            }]
            ,keys: []
    	});
    	yagUpload.window.UpdateContainer.superclass.constructor.call(this,config);
    };
    Ext.extend(yagUpload.window.UpdateContainer,MODx.Window);
    Ext.reg('yagupload-window-update-container',yagUpload.window.UpdateContainer);
    


    Then I’m setting data to the UpdateContainer window like this (right click menu item event from grid items) when I’m editing some item:
    Ext.extend(yagUpload.grid.Container,MODx.grid.Grid,{
        editContainer: function() {
            MODx.Ajax.request({
                url: yagUpload.config.connector_url
                ,params: {
    				action: 'mgr/container/get'
                    ,id: this.getSelections()[0].data.id
                }
                ,listeners: {
                    'success': {fn:function(r) {
                        this.windows['update-container'] = MODx.load({
                            xtype: 'yagupload-window-update-container'
                            ,record: r.object
                            ,listeners: {
                                'success':{fn:function() {
                                    Ext.getCmp('yagupload-grid-container').refresh();
                                },scope:this}
                                ,'hide':{fn:function() { this.destroy(); }}
                            }
                        });
                        this.windows['update-container'].setValues(r.object);
                        this.windows['update-container'].show();
                    },scope:this}
                }
            });
        }
    });
    


    That works ok.. But after I have used that UpdateContainer window and open a new CreateContainer window, via grid toolbar button setup like this:
    tbar: [{
                text: _('yagupload.create_new_container')
                ,handler: { xtype: 'yagupload-window-create-container' }
            }]
    


    the problem is that the CreateContainer window also has the data on the fields that was set with this.windows[’update-container’].setValues(r.object);

    So the questions are:

    What I’m doing wrong?
    How can I "reset" the window values after the window is closed?
    I thought that the ’hide’ listener does that with calling this.destroy();, but apparently not. What is it destroying then?
    Why the setting of the form values to a window with setValues() isn’t window specific? How the values come to that other window with completely different type?



      "He can have a lollipop any time he wants to. That's what it means to be a programmer."
      • 28215
      • 4,149 Posts
      Change:

      tbar: [{
                  text: _('yagupload.create_new_container')
                  ,handler: { xtype: 'yagupload-window-create-container' }
              }]


      to:

      tbar: [{
                  text: _('yagupload.create_new_container')
                  ,handler: { xtype: 'yagupload-window-create-container' ,blankValues: true }
              }]
      


      That *should* do it.
        shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • 7923
        • 4,213 Posts
        That did it, thanks!

        EDIT: Spoke too soon..

        It works now so that if I edit a item in the "yagupload-window-update-container" and then create a new one with "yagupload-window-create-container", the values are blank.. But after I have saved the new container in the create window, when I’m going to create another one the values that I just saved are on the window form..

        I don’t quite understand why? doesn’t that "blankValues: true" get set every time I use the toolbar button? Or is the window just created once and after I close it and open new create window again, it’s actually just showing the same window again.. So i need to clear the form everytime? Should I do some event listener to the window so that it clears the form values every time the window is shown?


          "He can have a lollipop any time he wants to. That's what it means to be a programmer."
          • 7923
          • 4,213 Posts
          Any idea Shaun?


            "He can have a lollipop any time he wants to. That's what it means to be a programmer."
            • 34127
            • 135 Posts
            I usually add a "reset" function for all of my window components which contains one line of code:
            reset : function() {
                this.fp.getForm().reset();
            }

            I also attach listeners to the window, one on "hide" (when the user clicks "cancel"), and another on "success":
            this.on( "hide", this.reset, this );
            this.on( "success", this.reset, this );


            This probably isn’t the best way, but I never managed to get the "blankValues" option working as I thought it should.
              • 28215
              • 4,149 Posts
              doze,

              It seems blankValues wasnt working on priorly-loaded windows. This has been fixed in SVN.

              Until then, feel free to just do an on show event after your Window’s constructor loads:

              this.on('show',function() { this.fp.getForm().reset(); },this);
              


              EDIT: Just as an FYI, MODExt is the least-refined part of Revolution; I’ve been going through recently in SVN and cleaning it up, adding events, etc. If you’ve got suggestions, I’m all ears - it needs some tightening, I’m sure.
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • 7923
                • 4,213 Posts
                Updated from SVN and it works not great, Thanks Shaun!

                I’ll be sure to report any issues I have, don’t worry smiley

                For now, everything has gone quite smoothly with this component development.. At first I was pretty intimidated with all these connectors, controllers, processors, extjs / modext objects, extending them and creating own types and and.. Seemed like a lot of work is needed to be done to build a component with manager page.. But once I got the structure and basics all set up, it wasn’t so hard after all.. I still don’t quite know what everything does (especially in the JS code), but getting there. I didn’t do any reading though that what the connectors, controllers and processors etc are, so I guess that’s why I was bit overwhelmed with all this too..

                Anyways.. Great stuff and hopefully you will see a file uploading component in a Provider near you in not too distant future... wink


                  "He can have a lollipop any time he wants to. That's what it means to be a programmer."
                  • 28215
                  • 4,149 Posts
                  Quote from: doze at Jun 25, 2009, 11:19 AM

                  For now, everything has gone quite smoothly with this component development.. At first I was pretty intimidated with all these connectors, controllers, processors, extjs / modext objects, extending them and creating own types and and.. Seemed like a lot of work is needed to be done to build a component with manager page.. But once I got the structure and basics all set up, it wasn’t so hard after all.. I still don’t quite know what everything does (especially in the JS code), but getting there. I didn’t do any reading though that what the connectors, controllers and processors etc are, so I guess that’s why I was bit overwhelmed with all this too..

                  Great! It’s easy to get overwhelmed at first by all the new concepts. There’s a lot - this is, after all, over 3 years of work in the making.

                  Connectors are simply secure gateways to processors - which are basically just the processing (affect the DB or filesys) parts of the script. Controllers load pages. Templates are the View of MVC - they show how it is to be displayed.

                  We moved Revolution to the MVC model because of it’s flexibility and power; and its easier to read. Then we extended the idea to MVC/C - where the 2nd C is connectors - to accomodate the two different ways in the web development world that the Model (Processors) is accessed - either directly on the same page, or through AJAX.

                  And as for the JS - well, I’m still figuring out what all it can do. tongue The idea was to make it as flexible as possible, extending ExtJS beyond what was provided and giving it a MODx look and feel. I’m all ears for ideas on simplification.

                  Thanks doze.
                    shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com