We have a quite big application built on the version 1.8.1. We would like to migrate to version 2.0 or higher. We have a few guestions:
Does exist some step-by-step manual how to do it?
Can we use 2 different versions of ember in the same time? Because of continuous migration...
We would like to avoid overwriting of the whole application...
I would suggest you to update the ember. and keep deprecation warnings open. Then you can try investigating each warning one by one and update the code with the new syntax.
This guide can be very useful : Upgrade to ember 2.x step-by step
Since Ember uses global window scope, it will result in conflicts and its not advisable to use two versions of ember.
It's possible to load different Ember versions based on which route you are on, but I really don't recommend doing that, as you lose all the benefits of having a Single Page App (apps will load again when you transition between them), and you end up doing significantly more work for yourself, with more opportunities to screw up. I'd follow locks' advice and upgrade the app step by step, testing as you go.
Related
I have an Ember app that uses several 3rd party add-ons. One of these add-ons uses Object.assign() which causes problem in IE11, specifically the error
Error: Object doesn't support property or method 'assign'
I know why this is happening, but I'm relatively new to Ember, and am not sure of the best way to handle/fix this. Based on my research, some options are:
Option 1: use polyfills (?)
I think there may be some additional libraries I can install, or options in Babel to set that will take care of this, but I have not been able to do so thus far. It's unclear whether any of these options would affect code from add-ons anyway, or if they only apply to code in the primary app.
Option 2: extend the add-on component to avoid Object.assign().
Unfortunately, the problematic lines are in the component's init(). When my extended component calls this._super(), the code I'm trying to avoid is run anyway. Is there a way to 'skip' the base component's init() and go straight to Ember's Component.init() (the add-on's _super()) ?
Option 3: ditch the 3rd party add-on, salvage what I can, and make my own component.
Irritating but do-able. At this point, it probably would have been faster to do that from the start.
Option 4: fix the add-on to remove the problem code. My hesitation here is two fold: 1, if this is something that I should somehow be managing within my app, it doesn't seem correct to make the add-on change (though there is definitely a 'best practices' argument to be made here). The bigger concern is that this is a low activity add-on. Even if I submit a PR with the change, I'm not sure how long it will take for a new release.
In the meantime, what would be the recommended practice? Point my app to a local build and then remember to update it to an 'official' version if/when it is released?
I suspect that Option 1, polyfills and/or build settings, is the most correct course of action, but I'm at a loss for what, specifically, to do.
Additional info:
My app was developed with Ember 2.7, and I am in the process of updating it to Ember 3.1. This issue exists in both builds.
You can include polyfill:
// ember-cli-build.js
let app = new EmberApp(defaults, {
'ember-cli-babel': {
includePolyfill: true
}
});
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
Just in my reading over the last few days I've found at least three different extensions offering data store support for Ember: ember-data, sproutcore-datastore, ember-ezdata, and I think I might be missing one.
This range of options gives rise to several questions.
Obviously ember-data is the "official" extension, but it's also pretty heavily fenced with qualifications ("This isn't ready for production") from the core team.
How should I compare and evaluate these options?
In the SproutCore 1.x series, development was usually done with fixtures, and the data source wired in later. Can any of these options support that sort of workflow? Can I load some production data this way (might change with release versions, but not user-editable) and other data from my back-end data source?
ETA: Here's a related question.
Personally, I'm expecting big things from ember-data, but it does seem to have a little way to go to be "production ready".
When I started using Ember, the ember-data project had just begun, so I decided to create a simple persistence layer of my own. I ended up with ember-rest, which is a pretty thin layer over jQuery.ajax(). You can see it in use in this Rails example. By the way, you can load JSON data directly into ember-rest without hooking into a backend.
I'm under the impression that sproutcore-datastore is no longer maintained. I've never tried ember-ezdata.
Another worthwhile option to check out is ember-resource.
I hope this is enough to get you started.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
Is there any guidance on how to write modular Ember.js apps? I have seen Tom Dale's position on AMD here so I am not going to force fit AMD on to the framework (as some have attempted here). It appears that Ember internally uses bpm/spade. Is that a reasonable approach to modularize Ember apps too? Any samples using this approach?
P.S. The getbpm.org site seems to be down which makes it difficult to learn about it. There is a github page but it refers to the site for install instructions.
BPM in it's current form is no longer supported by the core team, but is community supported. The only build tools they are officially providing support for is rake-pipeline. However, BPM does still work and it works well (I still use it with my projects). For info on how to use it see this: https://github.com/ud3323/bpm/wiki/Using-BPM-with-Ember. You may want to use my fork of bpm too. I've merged in Joe West's support for a proxy middleware.
There is also community build tools for node.js called ember-runner which looks promising as well.
As for using rake-pipeline. Look at the AssetFile on the emberjs projects to see how must be configured using rake-pipeline and rake-pipeline-web-filters. Also, take a look at the answers to this question on StackOverflow (especially Yehuda's). You may also find this gist helpful as well.
Try Ember App Kit - maybe it would help you.
I have played a bit with Rails, so for me, creating a rails 3.2 app was the easiest way to achieve this. So if you don't mind using rails as a back-end, I this might suit you.
Perhaps ember-tools could help:
https://github.com/rpflorence/ember-tools
I am novice still I found yeoman and ember-generator useful. In future you might need to add tests , mock rest calls you can easily npm install sinonjs and npm install ic-ajax