1. #11
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Not sure whether I'm glad to hear that others are frustrated too, since that wouldn't be the right way of putting it, but feel slightly more justified in my frustration now, so for what it's worth, thanks.


    Got my start page working now, it's as simple as implementing onLaunch in your apps page controller class.

    I did:
    Code:
        onLaunch: function(application) {
            if (application.startAction) {
                this[application.startAction]();
            }
        }
    Now have to wire up some grid buttons to another controller, which I suspect is going to be more painful...

  2. #12
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Right, have hit a brick wall I think...

    Quick overview.

    I have an application.
    It references two other repos that contain shared code, but not applications.
    In this shared code we have views, and controllers etc that will be shared between multiple products.
    Each shared area has a static class that mimics some of what application does via an init method, which sets up direct proxies, and the mvc namespaces and some static data and methods for the namespace.

    Now, in one of these shared views I need to access its controller.
    The problem is that controllers have to be bound to an application.

    Here's a cutdown view of what I was attempting.
    Code:
    Ext.define('Blah.View', {
    
        constructor: function() {
            // Kinda copied from Ext.app.Application
            var controllers = this.controllers,
                ln = controllers.length,
                i, controller;
    
            this.controllers = Ext.create('Ext.util.MixedCollection');
            for (i = 0; i < ln; i++) {
                controller = Ext.create(controllers[i]);
                this.controllers.add(controllers[i], controller);
                controller.init(this);
            }
        }
    });
    Then in a view, having:
    Code:
        mixins: {
            view: 'Blah.View'
        },
    
        controllers: [
            'Blah.controller.Foo'
        ],
    And obviously calling the mixin constructor in the class constructor.


    All seems good, until you try and call this.control in the controllers init method and use a ComponentQuery to try and reference something that you knew at the time of writing anyway

    I'm guessing I can keep hacking at it until it works, but would question the usefulness of this design.

    Are we really expected to put all controllers, views, etc into our single application entry point?!
    Talk about startup costs...

    Come back Ext.dispatch, all is forgiven!

    Thoughts?

    Cheers,
    Westy

  3. #13
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Ok, tried doing it the 'official' way, adding the referenced controller to my application controllers collection, and kaboom!

    It doesn't use the Loader class to resolve the path for the controller, just blindly chops it up and adds it on the end of the application + appFolder path

    Arrggh, suspect I may have to override applications getController or perhaps Ext.factory!


    I'd also argue this is a bug, but will wait for a dev to read it and agree first, if any have looked at this thread.

    Pint anyone?

  4. #14
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Just a quick update...

    Finally got the upgrade to beta3 sorted, at least for my most complete page.
    Had to change one of my referenced namespaces to have an application, so had somewhere to hang its controllers, then it all started to come together. Feels hacked in places thiough due to how we're forced to do stuff but don't think it can be helped at the moment.

    I have a few additional comments, if anyone's actually reading this (hello devs?).
    1. Having controllers responsible for hooking into event handlers is wrong I think, and prone to problems.
      I'd much rather have a control in a view tell it's controller what action to call, and be able to pass it stuff (yes, very much like Ext.dispatch)! Or maybe have the ability to do it either way?
    2. The ComponentQuery stuff used by Controller.control, whilst no doubt impressive from a technical point of view, makes no distinction about where the resultant controls come from. So the controller for a particular view can hook event handlers onto controls owned by a completely different view, forcing me to put in hidden ids onto some controls (so can effectively namespace them), ensuring that only the control in question is returned from a query. It should restrict to views that are referenced to the controller.
      I feel the ComponentQuery use has been forced into this because it's seen as some kind of silver bullet. Personally I rather not be querying for controls all over my application when I should just be able to pass references about as I need.
    3. The getters on controller seem useless, I've had to use control.up (yes, that's ComponentQuery again) to get to the view, which seems stupid, and a needless performance hit. The getters seem to return a useless object.
    4. Controller init gets called too late to hook into some events, such as an initial tabChange on a TabPanel. Thus I have a listener for this in my view, defeating part of the goal of this controller stuff surely.
    5. Having to have controllers owned by applications is needlessly restrictive, and forces too rigid a shape on us.
    6. Having the application, controllers, views, models and stores all tied together makes application startup far more painful (i.e. expensive) than it should be I think. I haven't bothered putting models or stores into my application or controller for this very reason, just 'requiring' them as needed.

    Glad I've finally sorted it though, only took part of my Sunday and the start of this week when I should have been wrestling with trees...

    Hope you think carefully before making any more huge changes to how things piece together, unless of course it is taking on some of the above, and making it us free to decide what owns what, and how comms between views and controllers are managed.

    Cheers,
    Westy

  5. #15
    Sencha Premium Member robboerman's Avatar
    Join Date
    Nov 2007
    Location
    Pijnacker, the Netherlands
    Posts
    75
    Vote Rating
    7
    robboerman is on a distinguished road

      0  

    Default


    All very good points Westy! I agree with all your points especially the first one.

    I would very much like to hear the Sencha viewpoint on this, hope someone reads this post and enlightens us.

    Cheers,
    Rob

    PS. I admire your perseverance! I have already given up on B3

  6. #16
    Ext JS Premium Member aenigmatic's Avatar
    Join Date
    Feb 2011
    Location
    Milwaukee, WI
    Posts
    9
    Vote Rating
    0
    aenigmatic is on a distinguished road

      0  

    Default oh the pain...

    oh the pain...


    I concur with the above. I spoke with someone from Sencha at a conference recently, and it seems the MVC model is being entirely reworked and will eventually be backported into Sencha Touch. I second (or twentieth) that an "official" explanation would be much appreciated. The MVC application examples are very shallow, which is a complaint I would lodge about all of the existing examples as someone who rarely gets to build such simple pieces.

    I recall reading something about an event bus, and there is a class in the framework (Ext.app.EventBus). This has a dispatch method etc.. and I wonder if it is intended to replace the previous methods of signaling.

    The "magic" methods for getters, setters, etc.. REALLY need to be explained clearly. Things like being able to init plugins via string reference vs active creation within an object configuration block, referencing stores via similar, etc.. There are an awful lot of things in the documentation that show multiple ways of doing the same task, but do not explain why a particular way was chosen.

    I know everyone at Sencha is working themselves into the ground to finish ExtJS4, but we need a definite launch roadmap including full documentation, or something similar, soon, so that we can make educated decisions about whether to back off on version 4 until it is stable and documented vs charge ahead with the hope it will soon be released. The YUI approach of adding a few (stable) pieces at a time provides a much more sure path towards upgrading from legacy to cutting-edge IMHO.

  7. #17
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    More developments for this discussion amongst us users

    So, you have an application that has your controller in its controllers collection.
    That controller references the view it "controls".

    Application gets created, onLaunch gets called, which calls init on your controller.
    Controller init uses ComponentQuery to try and add event handlers to buttons that HAVE NOT BEEN CREATED YET, because you haven't even loaded that view.

    How is this ever going to work? It just can't.

    I have a solution, and it's a peach.

    Controller:
    Code:
    Ext.define('MyControlerThatIsnt', {
        extend: 'Ext.app.Controller',
    
        statics: {
            myHandler: function(button, e) {
                // Do stuff
            }
        }
    });
    View:
    Code:
    //... blah blah
    {
        text: 'MyButton',
        handler: function(button, e) {
            MyControllerThatIsnt.myHandler(button, e);
        }
    }
    //...
    Works like a charm, no querying, no hassle, but completely bypassing the whole point.

    How do I get a dev to comment on this please?!
    Ideas anyone?

    Cheers,
    Westy

  8. #18
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    924
    Vote Rating
    47
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Should also add that I have no idea how the view/controller I have wired up is working.

    It appears that launch for my main application is firing, and executing, before onLaunch is firing for the other application (that owns the view and controller). Quite odd.

    Oh, and have PMed some devs in the hope to get some input to this thread

  9. #19
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045
    Vote Rating
    9
    stevil will become famous soon enough

      0  

    Cool


    As a Metallica (and Beatallica) fan, since it seems to align with the tortuous path you've followed, I'd suggest a name change:

    PHP Code:
    Ext.define('TheControllerThatShouldNotBe', {
        
    extend'Ext.app.Controller',

        
    statics: {
            
    myHandler: function(buttone) {
                
    // Enter Taxman
            
    }
        }
    }); 
    ok. off topic. i get it. this is what happens when you let the sleep-deprived onto forums without time restrictions.

  10. #20
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
    jan.harmsen is on a distinguished road

      0  

    Default


    My lessons learned from all Ext JS 4 preview + beta releases so far:
    MVC API has not reached stability, i.e. any application development starting now using Ext JS 4 MVC will very likely have to refactor more or less continuously with each release. I'm glad I found out before starting our next project with Ext JS. My company just doesn't have the resources to refactor with each release.

    I had hoped to find an 'official' statement from Sencha here.

    Well, maybe once 4.0 has been released.

    I think this version number '4' is quite misleading :-(

    My original post: http://www.sencha.com/forum/showthre...eta-3-MVC-woes.

Similar Threads

  1. GridPanel Woes...
    By Phunky in forum Ext.air for Adobe AIR
    Replies: 1
    Last Post: 8 May 2008, 1:58 AM
  2. autoScroll woes
    By junkzilla in forum Ext 2.x: Help & Discussion
    Replies: 4
    Last Post: 5 May 2008, 12:21 PM
  3. template woes
    By FMIC_DEV in forum Ext 2.x: Help & Discussion
    Replies: 1
    Last Post: 6 Feb 2008, 4:50 AM
  4. [2.0.1] Ext.urlEncode woes.
    By keithpitt in forum Ext 2.x: Bugs
    Replies: 1
    Last Post: 29 Jan 2008, 9:05 PM

Thread Participants: 8