Ember-data 1.0.0-beta.19: store.find() returns DS.INTERNALMODEL instances - ember-data

I have update Ember-data to 1.0.0-beta.19 and now store.find('events') resolved promise returns DS.INTERNALMODEL instances, instead of DS.MODEL. With Ember-data 1.0.0-beta.18 it was working fine. Any ideas?
UPDATE
At the end i found out that somewhere in my app code i was using Ember-data internal code like store.find('events.content'), causing an exception. The debugger was not so helpful tracing it, but removing this fixed my issue.

This is a bug, if the promise resolves with DS.InternalModel, those are only for internal use of Ember-Data and shouldn't be exposed to user code. Please file a bug if this is still a problem

This is on purpose. It's noted in the chanelog:
#3094 Lazily materialize DS.Models for app code, use InternalModel inside ED otherwise
It should work largely with no issues. Are you having issues with it?
You can access the DS.Model using InternalModel.record

Related

ERROR TypeError: Cannot read property '__source' of undefined

Since I upgrade to the new spartacus version (1.5) I've seen this bug in the console. It's came from SiteContextComponentService.getInjectedService.
I have not implemented nor used yet this service. How I can fix this bug? Cause I strongly believe is the origin of other little problems in my develop environment.
If you use 'CMSSiteContextComponent' component type (flextype?), then it should come with the context cms component data from the backend. Please check if the response contains it.
So the origin of the error was that in the GET /pages request I was not receiving the context attribute neither in the LanguageComponent nor the CurrencyComponent.

Syntax error handling in dojo 18n resource file

require(["dojo/i18n!myapp/nls/extTools_i18nStrings"],function(extTools_i18nStrings){
// Do something with the loaded file
});
If the resource file (extTools_i18nStrings) has syntax error, it will be shown in dojo.js. How can I handle it in my code?
Try catch block did not work.
Thanks in advance.
Error: Script error .............dojo.js:15
The quick answer is you don't want to. The right thing to do is fix the bundle. This is the same as having errors in your application code, and you would not expect the code to 'handle' that.
But since i18n is an AMD plugin running as part of the loader (which is why you can't try/catch it), the error might be reported through the AMD micro event API, and you could use that to show a better error. I'm not sure how you 'handle' this syntax error other than showing an error.
If you can't control the quality of the bundles via some part of your development or build process you'd have to invent your own alternative to dojo/i18n and you probably don't want to go down that route for all of your bundles.

Error building Shoutem preview build after modifying extension

I've working on modification of the 'shoutem.notification-center' extension using as a guide this tutorial and I'm having some issues.
At first I tried to use the Extend the extension approach, but like I've posted on this issue, didn't quite work.
So I've tried the Directly modify approach, which works fine on my local phone, but once I use the command shoutem push to send my modifications to the server, the instance on Appetize never stops the 'Building your application' message.
The major problem is that there's no error code or feedback.
That was not the first time that happened, I had the same issue modifying other extensions. Any idea why this is happening?
The issue is likely one of two things.
New native dependencies were added that the Builder preview cannot process due to it's predefined binary.
Your directly modified extension works locally, but not on the Builder because locally it's path is still AppName/extensions/shoutem.extName, but on the Builder it's AppName/extensions/yourDevName.extName, so it fails.
The first one can be resolved by either using a non-native solution as a replacement for the native dependency you were using, or to simply use a local emulator for previewing purposes.
The second can be resolved by making sure all extensions that reference the one you directly modified are edited to now reference your new directly modified extension instead of shoutem.extName.
If you could shoot me your app ID in a comment I can let you know which one it is and what the best steps to fix it would be.

Dojo console error objects empty

All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.

Eclipse plugin problem

When ever I try to do soft ware updates through my Eclipse Galileo, I get the following error
Unable to connect to repository http://pydev.org/updates/content.xml
Connection timed out: connect
Please help!!
That's a redirect to: http://update-production-pydev.s3.amazonaws.com/pydev/updates (so, you can try that directly).
If it still fails, it means that amazon is having issues (which means you'll have to try later again).
Cheers,
Are you using (just) http://pydev.org/updates as the url? The "location" field should only have "http://pydev.org/updates", no content.xml. Seems to be working fine for me (with Helios).
Actually I checked what happens when you use "http://pydev.org/updates/content.xml", and it does seem to give the type of error you describe. (You would think it could give a slightly better error, but oh well.)