On 08/28/2012 11:09 AM, non wrote:
>
> I had a look into these before. They use qx.io.ScriptLoader if I remember
> right.
> I like that approach, because I get rid of those add-scripts...
> But:
> * EXPERIMENTAL – NOT READY FOR PRODUCTION
Better use qx.bom.request.Script.
> * I don't understand, how this helps to get e.g. d3 loaded before class
> construction
It does not in- and out-of-itself solve the timing problem. But by
loading the d3 module programmatically in your code you get the chance
to provide infrastructure around it (e.g. by providing an .onload
method) and manage the timing issue.
>
> thron7-2 wrote
>> If you want a simpler approach, the first thing I would try would be to
>> remove the reference to the d3 class from the load-time location as a
>> map value, e.g. by setting
>>
>> period: null
>>
>> and then in the constructor of abc.core.View add
>>
>> this.period = d3.time.day
>>
>> The function wrapping you tried has the same effect, but the constructor
>> approach is in my view more natural, unless, of course, you actually
>> intend to share the d3.time.day object across all instances of your class.
>>
> Hm. Those are statics...
Ah, right. You could initialize the static member in the 'defer' of this
class. Picking up on the class wrapping approach I mentioned earlier,
something like this in abc.core.View
defer : function(statics) {
abc.core.D3.onload(function() {
this.period = abc.core.D3.getD3().time.day;
}, statics);
}
might do the job.
T.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
