《留言》的评论

作者：vini

vini — Thu, 17 May 2012 07:18:00 +0000

我除了会背诗，还能做什么呢。

背一首沧月写的：

君生我未生，

我生君已老。

隔了百年的光阴，

万里的迢递。

浮世肮脏，人心险恶。

割裂了生和死，

到哪里去寻找那一袭纯白如羽的华衣。

http://www.vini123.com

作者：vini

vini — Thu, 17 May 2012 07:12:00 +0000

人才啊。。。

作者：Simon

Simon — Tue, 05 Apr 2011 06:17:00 +0000

有合作做项目的打算么
yaoshi@ifengchao.com

作者：温泉

温泉 — Fri, 25 Mar 2011 06:31:00 +0000

明白了。
我是希望通过对RL和项目的一些实际情况来深入思考一下关于设计和架构上的问题。
谢谢您的意见！

作者：eidiot

eidiot — Fri, 25 Mar 2011 04:03:00 +0000

这个要具体问题具体分析了，通常View负责自己的子视图创建就可以。如果想要保持纯容器 View的松耦合，倒是可是把容器注入到 Command 里让 Command 来做。但这样的纯容器其实不会太多，否则就有些过度设计了。对于 View 来说通常不需要这种程度的松耦合。Robotlegs是个 Toolkit 而非 Framework，并没有严格的规定，主要是提供了 DI 支持和 event bus 的通讯方式。具体如何来分配职责可以完全根据需要来灵活处理。

作者：温泉

温泉 — Thu, 24 Mar 2011 11:29:00 +0000

额。。。继续来打扰。。。
所谓视图自己负责子视图的装配，也就是视图来实例化和持有子视图么？现在在我的代码里，我把子时图实例化的实现从command中搬到了Mediator中，因为子视图实例化的触发条件是监听model的。
在RL最佳实践中没有明确写着mediator不可以实例化其他视图类，当然我看到的几个Example里view和mediator都是一一对应的。
但是一旦我的容器视图需要自己实例化子视图，那容器的耦合性就被抬高。因为我的容器只提供一个addElement的方法来向内添加子元素。
如果mediator和view都不适合去构造子视图，那是不是应该做一个manager去管理？

再次感谢

作者：温泉

温泉 — Thu, 24 Mar 2011 03:11:00 +0000

谢谢指正！！

作者：eidiot

eidiot — Wed, 23 Mar 2011 00:24:00 +0000

相反，通常 Command 是不负责视图的装配的，而且试图类一般不会提供依赖注入。视图一般自己负责子视图的装配。

作者：温泉

温泉 — Tue, 22 Mar 2011 13:26:00 +0000

您好，看了您很多关于Robotlegs文章，开始学习Robotlegs，现在有一个问题想请教一下。
假设，我有一个视图类，它被作为一个容器，然后另外还有几个视图类将会被置入进这个容器内。
Command是否是执行这种逻辑的最佳场所？也就是说command持有了几个视图类，然后对其操作。
这些需要被command持有的视图类，都需要用mapValue或者mapClass注入到注射器中，如果这样的视图类过多，是不是不好？
另外，如果上面command可以持有多个视图类这个说法成立，那我是不是可以理解，command就是整个RL体系中，进行耦合的唯一场所，当然实际上因为command生命周期短，所以实现了低耦合？

作者：eidiot

eidiot — Mon, 06 Dec 2010 07:18:00 +0000

UI框架本来和 Module 就是不相干的。你可以自己研究下 Flex 的 Module 机制然后自己实现，或者找找有没有第三方类库。其实很简单的，建议看看 Flex 的源码自己研究。