PDA

View Full Version : PRx to PR4 Migration Gotchas



bweiler
24 Jan 2012, 2:21 PM
Here's a list of gotchas migrating from PRx to PR4. You should also read the release notes, but this should help. I'll add more gotchas as I find them.

Hope this helps


* xtypes are now required on all views. They used to be generated automatically.

* Models are no longer referenced by get[ModelName]Model(). It looks like the new approach is: this.getModel('modelName').

* Arrays are now required when adding models to stores (store.insert(0, [{category: label, optional: true}]);

* Setting extraParams directly is no longer supported (proxy.extraParam.req = 'getRecord'). Use proxy.setExtraParam('name', 'value').

* Store.count() has been replaced with store.getCount().

bweiler
24 Jan 2012, 2:54 PM
* store.filterBy() has been replaced by store.filter()

edspencer
24 Jan 2012, 2:56 PM
Thanks for kicking this off, I'll keep an eye on the thread and update the migration guide accordingly

bweiler
24 Jan 2012, 10:16 PM
* view.create() does not default to flex: 1

widged
25 Jan 2012, 4:42 AM
From pr3 to pr4 custom paths cannot be used anymore with views and controllers declarations.


controllers: ['App.Section.Controller.SectionController']
views : [ 'App.Section.View.Main' ]

trigger errors like:


[Ext.Loader] Failed loading 'app/controller/Section/controller/SectionController.js', please verify that the file exists


(the actual path is 'app/Section/controller/SectionController.js')

It is not clear how a custom path can be defined within a controllers.

In pr3, in Ext.app.Application, a controller path was extrapoloated with:

this.getModuleClassName(controllers[i], 'controller').

In pr4 this has apparently become:

format('{0}.controller.{1}', name, controllerName), name, controllerName);

On the one hand, it has become mandatory to use the word controller in the path. On the other hand, it is mandatory to have the application name as the first and only item preceding controller.

This is not practical for big applications that benefit from splitting the code into separate sections, each with its own path.

Possibly a bug - http://www.sencha.com/forum/showthread.php?176429-PR4-Custom-folder-structure-for-MVC-no-longer-supported

estesbubba
25 Jan 2012, 6:44 AM
Here is what I have found:

Application
- init() is no longer called

Controllers
- launch() is no longer called
- refs goes into config {}
- this.control goes into config {}
- this.application is now this.getApplication()

Views
- initialize(): this.callParent() needs to be called before this.setItems() otherwise an changed layout error occurs

bweiler
25 Jan 2012, 1:07 PM
The following worked in PR3, but in PR4 it changed.



this.control({
'mainview #SettingsButton': {
tap: this.onSettings
},
});


The following is the new approach for PR4 (this example uses a selector, but now refs can also be used):



config: {
control: {
'mainview #SettingsButton': {
tap: 'onSettings'
},
}
}
...
onSettings: function() {
console.log("onSettings");
}

edspencer
25 Jan 2012, 1:09 PM
Calling this.control (your first block) should still work though

bweiler
25 Jan 2012, 1:11 PM
Here is what I have found:

Application
- init() is no longer called

Controllers
- launch() is no longer called
- refs goes into config {}
- this.control goes into config {}
- this.application is now this.getApplication()

Views
- initialize(): this.callParent() needs to be called before this.setItems() otherwise an changed layout error occurs

You probably already figured this out, but you can call launch() in the app and init() in the controller. This did not change between PR3 and PR4.

bweiler
25 Jan 2012, 1:23 PM
Figuring out the Sencha errors that are thrown is the time consuming part. Conforming to the new PR4 approach is trivial and I really like the changes to PR4. ST2 is amazing!

TommyMaintz
27 Jan 2012, 4:33 PM
* store.filterBy() has been replaced by store.filter()

This was actually a bug and has been fixed for the next release.

KJedi
27 Jan 2012, 5:26 PM
Store.load is broken if you use Ext.data.proxy.Rest because in buildUrl there is a nice code:

buildUrl: function(request) {
var me = this,
operation = request.getOperation(),
records = operation.getRecords() || [],
record = records[0],
format = me.getFormat(),
url = me.getUrl(request),
// @TODO: put back the operation id
//id = record ? record.getId() : operation.id,
id = record.getId();

if (me.getAppendId() && id) {
if (!url.match(/\/$/)) {
url += '/';
}

url += id;
}

if (format) {
if (!url.match(/\.$/)) {
url += '.';
}

url += format;
}

request.setUrl(url);

return me.callParent([request]);
}
Guess what happens if you do not have records passed with operation?

By the way, how can stupid errors like this slip through the unit testing process Sencha claims to have?

Fix is trivial:

Ext.define('CJ.overrides.RestProxy', {
override: 'Ext.data.proxy.Rest',
buildUrl: function (request) {
var me = this,
operation = request.getOperation(),
records = operation.getRecords() || [],
record = records[0],
format = me.getFormat(),
url = me.getUrl(request),
id = record ? record.getId() : operation.id;

if (me.getAppendId() && id) {
if (!url.match(/\/$/)) {
url += '/';
}

url += id;
}

if (format) {
if (!url.match(/\.$/)) {
url += '.';
}

url += format;
}

request.setUrl(url);

return me.superclass.buildUrl.apply(this, [request]);
}
});

KJedi
27 Jan 2012, 5:34 PM
Application simply will not start if there is no icon, because the Ext.application or Ext.setup code assumes there will be at least one icon.
Sure, that's a bug and compatibility issue.

edspencer
27 Jan 2012, 5:53 PM
The Application icon bug is already fixed locally (sorry about that :/), so is the RestProxy id issue. We're working hard to get a new release out in a few days

KJedi
28 Jan 2012, 10:50 AM
Ed, nice to hear about that. I just think that better testing, even of the PR releases would have better impact of Sencha team image.
Those 2 issues took me around 1.5 hours to figure out and fix (overrides were changed as well, wanted to use the new version)

edspencer
28 Jan 2012, 11:00 AM
Well that's a fine line - some ask for early previews, some ask for stability. Hopefully we make it pretty clear what you're signing yourself up for when we ship PRs - it's in their nature that they're not as stable as a beta, otherwise they wouldn't be preview releases :)

In this case though the icon bug was pretty severe, we should have caught that. I do think we're doing much better across the board when it comes to QA (PR4 is pretty stable overall) but we can always improve. It's a process. As always we're grateful for you guys helping us out.

rhomb
29 Jan 2012, 12:43 AM
Model.load() need model attribute specified

Here is the link

http://www.sencha.com/forum/showthread.php?176411-PR4-Model.load()-broken

w (http://www.sencha.com/forum/showthread.php?176411-PR4-Model.load()-broken)orkaround / solution is in the thread aswell :)

pkellner
30 Jan 2012, 2:08 PM
Details and example project here:

http://www.sencha.com/forum/showthread.php?176914-Trouble-catching-panel-show-event-with-MVC-PR4

mike lebowski
31 Jan 2012, 5:50 PM
might want to make this topic sticky.

mike lebowski
6 Feb 2012, 11:42 PM
The following worked in PR3, but in PR4 it changed.



this.control({
'mainview #SettingsButton': {
tap: this.onSettings
},
});


The following is the new approach for PR4 (this example uses a selector, but now refs can also be used):



config: {
control: {
'mainview #SettingsButton': {
tap: 'onSettings'
},
}
}
...
onSettings: function() {
console.log("onSettings");
}


Are you saying the old approach
tap: this.onSettings
is no longer valid? Or only that the string based approach is a valid alternative? (e..g tap: 'onSettings' )

edspencer
7 Feb 2012, 10:23 AM
They should both still work - the new config approach is just more convenient...

mike lebowski
7 Feb 2012, 10:31 AM
hmm, the prior style did not seem to work for me so i switched to the new approach. I was dealing with a lot of very unclear "not an object" errors following upgrade from PR3 to beta, and out of desperation I changed the mapping style to conform to the new approach, but maybe they were not causing the errors.

The older style had some advantages, for example small inline event hanlder functions could be written right there in the declaration.