好的,所以我想我可以更清楚地表达我想要完成的事情。
为了节省时间和代码编写,我想创建一个模块/小部件,其中包含其他dijit,如BorderContainer,TabContainer等。我希望该模块是程序化的而不是基于模板的。
在index.php中,我想像我这样加载我的应用程序......
我的第一个问题是......
这是创建包含其他小部件/模块的模块的正确方法吗?
我的下一个问题是......
我的SuperScreen.js结构应该是什么样的?
现在,看起来像这样......
但显然这不起作用。
对“bc”的引用在构造函数中,因此它自然不适用于placeAt函数调用。
我的边框容器应该在构造函数中还是其他地方?
似乎声明函数允许继承。我很困惑,因为我不想从BorderContainer继承,我只是想使用它。
答案 0 :(得分:3)
第一个问题:简短答案是肯定的,
然后要使bc对placeAt可见,你可以在SuperScreen.js中执行此操作:
define([...], function(...){
var bc;
return declare(null, {
constructor: function(args){
bc = new BorderContainer(...);
},
placeAt: function(){
bc.placeAt(...);
...
}
});
});
或者你可以这样做:
define([...], function(...){
return declare(null, {
constructor: function(args){
this.bc = new BorderContainer(...);
},
placeAt: function(){
this.bc.placeAt(...);
...
}
});
});
在第一个解决方案中,bc是一个静态变量,对构造函数和placeAt都是可见的。然后它在SuperScreen的所有实例之间共享,如果SuperScreen只被实例化一次,这没有任何害处。你仍然应该使用第二种解决方案,至少"以防万一"。如果您打算多次实例化SuperScreen,那么解决方案2是必需的,其中每个SuperScreen实例有一个bc(一个不同的BorderContainer)。
这就是为什么在只需要一个实例的情况下,我更喜欢一个返回普通对象的模块,而不是一个类,因为我觉得它传输了正确的语义(一个实例化的类实际上不需要是一个类和dojo / define允许这样做,所以我使用它!),最后它会产生更简单的代码:
:
require ([SuperScreen], function(){
SuperScreen.prepare();
superScreen.placeAt(document.body);
});
:
define([...], function(...){
return {
prepare: function(args){
this.bc = new BorderContainer(...);
...
},
placeAt: function(){
this.bc.placeAt(...);
...
}
});
回答你的问题"你的BorderContainer应该在构造函数中还是其他地方?":
yourSuperScreen是一个类,而不是一个小部件 - declare(null, function(...){})
- 构造函数是您唯一的选择。有关declare和dojo类的更多详细信息,请参阅dojo文档here。
如果它继承自dijit / _WidgetBase - declare(_WidgetBase, function(...){})
,它将是一个小部件,在这种情况下,您将在dojo doc here中解释选择,postCreate()是最喜欢的(引用)文件,"到目前为止最重要的方法要牢记......");
以上内容可能会回答您的上一个问题:不用担心您确实只是使用BorderContainer,而不是继承它。
答案 1 :(得分:2)
这是一个很好的入门项目 - https://github.com/denov/dojo-demo
HomePage.js非常接近你的SuperScreen.js