dojox/mvc & markup initialisation concern, "at" functions not called until widget startup

[edchat]

cjolif sent the following via email:

I was facing an initialization issue (i.e. the gauge value being updated twice once with its default value and then with the value given by the binding which was not happening if I was not using binding) and so I debugged this a little bit and discovered that during widget initialization the "at" functions are not resolved during creation but only at startup of the widget (thus my issue, I get the default value first and then after startup the one resolved from the binding).

I can probably workaround the issue on my side, but I was wondering what was the rational behind that? In Dijit the lifecycle is such that parameters are applied during creation not startup so why dojox/mvc does it differently? Should dojox/mvc keep with that? Or did you have particular issues to do it like that?

---

asudoh responded with this:
Hi Christophe,

Resolving data binding declaration at startup() lifecycle event was the approach 1.7 dojox/mvc code took too, and I also wondered why. After several analysis on the scope of dojox/mvc, I decided to keep that approach for 1.8 at() binding, from the following reasons:

set() in dijit/_WidgetBase may end up with setting DOM attribute, and DOM node not being ready at then causes JavaScript errors.
If data binding target is to be created in the same dojo/parser.parse() call, it may not be created until dojo/parser.construct() runs against all widgets. startup() runs after then, so it's a safe way to make sure data binding target is there.

Your point of difference between the lifecycle point of Dijit's parameter resolution and the lifecycle point of data binding resolution sounds still valid to me. I think it's a good topic to discuss further for 2.0.

---

cjolif responded with this:
Hi Akira,

For your point #1. The idea was not for MVC to call set, but in its postscript override to avoid removing the attributes with a binding and instead set their value to the result of the binding call. You would not call set() explicitly but just foward back the value to the widget postscript. It should work otherwise it means the widget is broken.

For your point #2. I understand this. Maybe in the phase #1 above if the binding can be resolved it is, and the value is send to the postcript of the widget. If not then it is gathered to be like it is today computed at startup?

In which case we should have the best of both worlds?

asudoh responded with this:
Hi Christophe,

Below ideas makes sense to me. It may be risky for 1.9, but it definitely worth considering for 2.0. (Or we may make such change in behavior opt-in in 1.9 timeframe).