Strange behavior in ember 1.13.* - ember.js

I have a controller ApplicationController with controllerInt and controllerString properties.
And I have a component RedSquareComponent with componentInt and componentString properties.
I bind controllerInt and controllerString to componentInt and componentString via hbs-template, componentString=controllerString="VALUE FROM CONTROLLER".
In RedSquareComponent I also have .on('init') method which set "SET ON INIT" value to componentString.
I've added an action to component to handle click on some object (red square) and set some value (for example, 1) to componentInt.
But when this action works -- componentString also changes (I don't know why), and become equal to "VALUE FROM CONTROLLER".
Is it a really expected behaviour?
The same code works fine on Ember 12.4, but I have checked it on several 13.* versions - it doesn't work.
https://jsfiddle.net/AlexeyBedonik/a23ev98w/3/

In your case, if you just change .on('init') part to .on('didInsertElement') it will fix your problem.(that means it will update both controller and component componentString property to 'SET ON INIT'.)
But you should not change values on a parent that are rendered already is deprecated. so you will get deprecation warning.
To get more info about this issue/bug follow this discussion.
It's good to follow/understand below concepts.
1) Passing properties to component by default it is two-way data binding
2) To update data always follow the Data Down Actions Up priniciple (DDAU)

Related

Ember ember-views.render-double-modify

Using Ember.2.1.0-beta4
I am getting the "ember-views.render-double-modify" in a function triggered by the "didReceiveAttrs" of a subcomponent.
I tracked down the statement this.set('_columns', columns) that triggers the error. However, AFAIK this is the first time the attribute is modified.
To debug it, I created an observer for the modified attribute, and put a breakpoint there. However, the observer is only called once and the error is still there, so it looks like this is the first call.
How should I debug this -- is this an Ember bug, or are there other restrictions on setting attributes that aren't clear in the error? Note that the attribute is used in the component's template. Also the attribute is used in other computed attributes (e.g. _columns.#each.width and _columns.[]).
For posterity's sake, the answer in my case was: _columns is used in the template. Thus, for didReceiveAttrs of the subcomponent to be called, the previous value of _columns was already used.
The error message is a little misleading, but the idea, I think, is that once you start to render you can't change properties until you are done. If necessary, use Ember.run.scheduleOnce('afterRender', ...).

"Cannot call method 'destroy' of undefined" in arrayWillChange

I have what I think is a pretty standard array/template relationship setup, but when I push a new item into the array I get the above mentioned Cannot call method 'destroy' of undefined error in the arrayWillChange method of the Ember source:
for (idx = start + removedCount - 1; idx >= start; idx--) {
childView = childViews[idx];
if (removingAll) { childView.removedFromDOM = true; }
childView.destroy(); <-- childView is undefined
}
I have never had this issue before. This doesn't happen when I remove an item from the array. Only on addition. Below is a link for a JSBin where I tried to duplicate the issue. The error doesn't get thrown but the template doesn't update either.
http://jsbin.com/asemul/2
EDIT:
You're calling array.push instead of array.pushObject -- the latter is an Ember.js method that is binding aware, which means it will automatically update bindings for you. The handlebars template helper {{#each filters}} is a binding to the filters array of the controller, and the template needs to know to update when the underlying array is updated. push doesn't tell the binding to update, but pushObject does.
Here's a working example (all I did was change push to pushObject): http://jsbin.com/asemul/6/
This is a pretty common mistake -- usually, I find that if my templates aren't synchronized with the underlying object, it's because something's wrong with the bindings, so that's where I start looking.
END EDIT
I don't think you should be setting removedFromDOM directly -- try using childView.remove() followed by destroy().
I'm not sure what the context is, but have you looked at ContainerView or CollectionView? Both of those views have support for arrays of child views and may accomplish what you're looking to do both more robustly and with less code.

How to programatically change TFS 2010 workitem link-type

I've used the tfs api to programatically add links between work items in different team-projects, currently all links are set as related links but I'd like to change some of them to some of the other types supported in tfs2010 e.g. "parent" etc. But I can't work out how to do it. Any ideas?
Edit:
Originally I added thus:
RelatedLink link = new RelatedLink(iLinkMe);
wi.Links.Add(link);
when I think I should have added:
WorkItemLinkTypeEnd linkTypEnd = store.WorkItemLinkTypes.LinkTypeEnds["Parent"];
RelatedLink linkBetter = new RelatedLink(linkTypEnd, iLinkMe);
wi.Links.Add(linkBetter );
but I didn't, (and I don't like the "Parent" string, I was looking for an enum), so how do I change the linkTypeEnd? I'm guessing I can modify this via wi.Links ?
Have a look at this site on how to Create Link Between Work Item (Parent, Child etc…).

Playing with Ember.Object.reopen(), why I have those results?

I was trying to answer this question: emberjs: add routes after app initialize()
I started to play with Ember.Object.reopen(), to understand how it works, and perhaps finding a way of answering the previous question.
I feel a bit puzzled, and don't understand the behavior of this code:
jsfiddle: http://jsfiddle.net/Sly7/FpJwT/
<script type="text/x-handlebars">
<div>{{App.myObj.value}}</div>
<div>{{App.myObj2.value}}</div>
<div>{{App.myObj3.value}}</div>
</script>
App = Em.Application.create({});
App.MyObject = Em.Object.extend({value: 'initial'});
App.set('myObj', App.MyObject.create());
Em.run.later(function(){
App.get('myObj').reopen({
value: "reopenOnInstance"
}); // the template is not updated, 'initial' is still diplayed, but
console.log(App.get('myObj').get('value')); // print 'reopenOnInstance'
App.MyObject.reopen({
value: "reopenOnClass"
});
App.set('myObj2',App.MyObject.create()); // the template is updated and
console.log(App.get('myObj2').get('value')); //print 'reopenOnClass'
App.myObj3 = App.MyObject.create(); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'reopenOnClass'
Em.run.later(function(){
App.get('myObj').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj').get('value')); // print 'setWithSetter'
App.get('myObj2').set('value', "setWithSetter"); // the template is updated and
console.log(App.get('myObj2').get('value')); // print 'setWithSetter'
App.myObj3.set('value', "setWithSetter"); // the template is not updated but
console.log(App.myObj3.get('value')); // print 'setWithSetter'
}, 2000);
},2000);
If someone can explain what is going on, particularly why the templates are sometimes not updated, sometimes updated, and also what's the difference between calling reopen on a class, calling it and on a instance.
Not 100% sure, but I will try and answer you questions.
First lets look at "myObj3". The ember getter/setter methods trigger the updates in the templates (they fire internal events which cause every property/observer to know something happened). Just setting a value by hand does update the value but will not fire these events and hence nothing changes in the UI. Kind of like when you use a Mutable list you use pushObject to make sure the UI updates.
Now lets look at your "reopen". When you reopen on the class it works as you would expect and updates the base class. When you reopen an instance it is actually creating a mixin and shims it on top of the object. This means when you do a "get" ember iterates over the mixin & object for the value to return. It finds that mixin and gets the value before the object; you could actually replace the method with a "return 'foo '+this._super()" on the instance you will get 'foo initial' (think of your object has having layers like an onion). If you have a group of mixin on top of your object you will have a hard time finding the correct value if you set something directly (but "get" will work perfectly). This leads to the general rule that you should always use "set" instead of a direct reference.
Side note: You can call "getPath" instead of "get" and you can use the relative or absolute path. Such as App.getPath('myObj2.value') which will make the code a little easier to manage. Goes for "setPath" also.
Lastly: The last value prints because you did change the value (it is in there) but the trigger for ember to update the ui never fired because you never called set on "myObj3" object.
EDIT: In the lastest version of ember it looks like the reopen on an instance does do a merge-down on the object (if that key already exists). The mixin only will wrap if you are adding new content.

Coldfusion 8 - mapping conflict causes "argument is not of interface type" error

I have been researching this, and cannot seem to find anything about it.
We work on CF8. When my coworker tried installing my latest code updates, he started seeing errors that the argument supplied to a function was not of the specified interface type. Worked fine for me. Same set up. Sometimes it works for him. Also have the problem on our dev server.
I have since been able to isolate and reproduce the problem locally.
Here is the set up.
I have 2 mappings on the server:
"webapp/" goes to c:\webroot\
"packages/" goes to c:\webroot\[domain]
Then I created an interface, call it ISubject and a component that implements it, called Person, and saved both under packages. Here is the declaration for Person:
cfcomponent implements="packages.ISubject"
Finally, there is a component, called SubjectMediator with a function, called setSubject, that wants an object of the ISubject interface type. Here is the argument declaration for setSubject:
cfargument name="subject_object" type="packages.ISubject"
To implement:
variables.person = createObject("component", "packages.Person").Init();
variables.subjectMediator = createObject("component", "packages.SubjectMediator ").Init();
variables.subjectMediator.setSubject(variables.person);
That last line throws the error that Person is not of type ISubject. If I do isInstanceOf() on Person against ISubject it validates fine.
So the reason this is happening? Dumping getMetaData(variables.person) shows me that the interface path is webapp.[domain].ISubject. And indeed, if I change the type attribute of the argument to use this path instead of packages.ISubject, all is fine again.
Coldfusion seems to be arbitrarily choosing which mapping to resolve the interface to, and then simply doing a string comparison for check the type argument?
Anyone had to contend with this? I need the webapp mapping, and I cannot change all references to "packages" to "webapp.[domain]." I also am not able in this instance to use an application-specific mapping for webapp. While any of these 3 options would circumvent the issue, I'm hoping someone has some insight...
The best I've got is to set argument type to "any" and then check isInstanceOf() inside the function... Seems like poor form.
Thanks,
Jen
Can you move the contents of the packages mapping to outside the webroot? This seems like the easiest way to fix it.