Beta3 upgrade woes...

[westy]

Well, this is not going particularly well

Have updated my application, and all controllers and models to not use their 'reg' methods, but be classes in their own right (with I think is a good idea btw, although would be nice to be able to include requires and statics in an application).

Seems that 'pages' are no longer controlled by a controller though, apps have no 'defaultUrl', and there is no Router or Dispatch!
What are you meant to do now then? The guide only has a single 'page' so that's not much use in this instance (although is a step in the right direction I think).

For now am just putting my default page action into launch for now, just to get something on screen.
Now hit an issue with 'layout.setOwner' is not a function... can see it getting called ok for lots of other layouts (after putting breakpoint on it), but the one it errors on is 'fit', i.e. a string and not an object.

Not got time to come up with an example case at the moment, since my control structure is a little complex, but anyone else seen this, where a layout instance has not been created properly from the string?

Appreciate any help.

Cheers,
Westy

[steffenk]

i also have some problems to follow
If i look to the nested loading examples, there are some magics inside, like:

me.getBookSideBar()

or

me.getBookView().bind(record);
me.getReviewList().bind(record, me.getReviewsStore());

As these functions are not in code they are "magic" and not mentioned in the guide yet.
Also the new syntax from the guide:

this.control({
    'viewport > panel': {
        render: this.onPanelRendered
    }
});

cool with component query, but normally you would prefer named ones.
The nested loading use "selectors" in "refs", also not mentioned anywhere.

Hard to get a complete picture without debugging example apps.

westy, i think the control function is the one to use, also to change the views. it would be nice to have at least one example which uses different views in viewport, exchanging them etc.

[westy]

Thanks for the reply.
Yeah, suspect need to have a look at the control stuff, had enough for today though...

Could those getters be like the automagic ones created by initConfig but for views and bbars perhaps?

[Nickname]

A quick look into the sources and your good

In the controller definition you have

Ext.define('Books.controller.Books', {
    extend: 'Ext.app.Controller',
    
    models: ['Book'],
    stores: ['Books', 'Reviews'],  // <-- Reviews store => getReviewsStore()
    
    refs: [
        {ref: 'bookSideBar', selector: 'booksidebar'},
        {ref: 'bookView',    selector: 'bookview'},  //<--- ref: bookView => getBookView()
        {ref: 'reviewList',  selector: 'reviewlist'}
    ],
/... 

And in the Ext.app.Controller.js it takes the "refs" to generate the methods

        constructor: function(config) {
        this.mixins.observable.constructor.call(this, config);

        Ext.apply(this, config || {});

        this.createGetters('model', this.models);
        this.createGetters('store', this.stores);
        this.createGetters('view', this.views);

        if (this.refs) {
            this.ref(this.refs);       // <-- generate magic component query view ref
        }
    },
    createGetters: function(type, refs) {
        type = Ext.String.capitalize(type);
        Ext.Array.each(refs, function(ref) {
            var fn = 'get',
                parts = ref.split('.');

            // Handle namespaced class names. E.g. feed.Add becomes getFeedAddView etc.
            Ext.Array.each(parts, function(part) {
                fn += Ext.String.capitalize(part);
            });
            fn += type;

            if (!this[fn]) {
                this[fn] = Ext.Function.pass(this['get' + type], [ref], this);
            }
            // Execute it right away
            this[fn](ref);
        },
        this);
    },

    ref: function(refs) {
        var me = this;
        refs = Ext.Array.from(refs);
        Ext.Array.each(refs, function(info) {
            var ref = info.ref,
                fn = 'get' + Ext.String.capitalize(ref);
            if (!me[fn]) {
                me[fn] = Ext.Function.pass(me.getRef, [ref, info], me);
            }
        });
    }, 

In the createGetters() method the little nice comment, that namespaced stores, models and views are concatenated can be a pitfall.

For the ComponentQuery: You can still use the xtype (or alias)

this.control({".xtype_name": render: {}});
this.control('.gridpanel') 

[westy]

Ok, after another hour of head scratching have got something on screen... changing a panel from a JSON object with an xtype to an Ext.create got around the layout string issue, although I have no idea why!

Unfortunately nothing is laid out correctly now; two panels that should be in a border layout, with a split have only the top one showing; a very simple form panel for login now has no height!! Quite a mess!

I really think the changes in beta3 are far too sweeping to warrant the fact we ever hit beta.
I seem to remember the API was meant to be static once we got to beta?

Oh well, guess I have to live with it and try and sort it out. Going to waste the best part of a day though where I should be wrestling with the new tree (or is that a table )!

Frustrating....

[westy]

Seems that setting bodyPadding on the form panel gives a height to it content... very odd...

[robboerman]

Hi Westy,

I am frustrated about the changes in Beta3 as well. Besides a lot of new bugs that have been introduced the API has completely changed, namespaces have been completely reshuffled and the examples are either minified or using black magic.

Up until Beta 2 I was very excited about the changes and the rate of bug fixes, but not so much now. In fact, I am thinking about dropping ExtJS 4 altogether until a final release is available. I spent a lot of time creating an application that worked on Beta 2 which now has to be completely rewritten. I understand that some changes still need to make it into the release, but changes like these, without any warning or description, is not very nice to the development community that is participating in testing the beta (?).

[westy]

Yeah, it's frustrating... lots of new issues have appeared it seems.

I'm making progress, but am now trying to fathom how controllers are meant to get wired up to things that are not as simple as 'example' in the guide. That and figuring out how to do pages properly.

I had a controller mechanism that I was happy with, using a View mixin I created that forced a view to specify its controller, then dispatched to that. Simple, and effective...

Not sure I like being forced to use ComponentQuery when I know at the time of writing what I want to call within looking in the DOM at runtime!

I hope they get a bugfix release out asap, since this is like going back to PR1 or 2 for the amount of issues.

[estesbubba]

We feel your frustrations too. Here were all along creating our MVC application and beta 3 completely changes everything. Since we wrote a mobile application using Touch MVC we used that model for Ext JS 4. Now everything has completely changed and our application is whacked. We used Ext.dispatch and Ext.router and they are completely gone.

We have a lot of questions right now.

[robboerman]

Hah, that's almost exactly what I did. I specified the controller in the view using the Sencha Touch method of putting it in the .view namespace and then dispatched events and stuff to methods in the controller. The handler only received data it needed for handling the event.
Apparently Views in the new MVC should not know about the controller (as I was told in another thread), but that sounds a little rigid to me. Now the whole controller-view mechanism depends on:
1. The view having an xtype alias, otherwise the controller cannot find it using CQ
2. The controller needing to know where the view roughly is ('viewport > userlist') instead of just using events
3. The controller needing to know what parameters an event from the view sends (or hardcoding view structure into the controller)

It all sounds a little unconfortable to me. At the one hand a lot of work is done on trying to split up everything into views, controllers, models, views, but on the other hand things can only work when controllers know about views and vice versa...

I am stopping my efforts on B3 for now before I pull all my hair out in frustration. Good luck with your efforts!