controller需要renderChildAction功能 about er

[DDDBear]

考虑到一个Action中可能会包含多个popupAction，还会有一个popupAction中包含另一个popupAction的情况，是不是需要提供类似parentAction的参数做关联？或者 isChildAction 这个就换成 parentAction？

[otakustay]

@DDDBear parentAction的作用是什么？

我的最终目标是，一个Action无需关心自己是否为 chidAction ，由框架来做平滑的过渡，因此当加载一个子Action时，父和子Action之间的交互应当是 由子Action开放事件和方法，由父Action监听事件并调用方法 。

在这种设计下，子Action完全不需要知道父Action的存在，只要明白 自己会被其它地方接入 而因此 开放足够的接口 即可。

在现有的产品线下，是否有具体的业务需求场景，用以上的 父 -> 子 的单向依赖关系无法解决，而必须改为双向知晓和依赖的场景？

[DDDBear]

@otakustay 看了下我们这边的产品代码，我之前实现的确实是“子嵌套”的概念对于Action本身是透明的，url跳转所涉及的对子Action的同步销毁也是在controller里进行。唯一需要分父子情况考虑的就是那些Action内部的链接元素，处理方法跟你说的是一样的。不过后期期待的改进就是能够把这一步也抽取到外部来统一实现。

[otakustay]

@DDDBear 在你们的开发过程中，子Action和父Action的区别有哪些，我总结了2条：

• 不能使用<a>元素或locator.redirect来直接修改URL中的hash，要管理起来转为另一个renderChildAction的执行
• 不能从URL中通过 isModify 等关键字来判断Action的类型

还有没有别的，麻烦一起总结一下

[DDDBear]

@otakustay 其实只要是涉及使用地址栏url的都要区分处理。比如截图工具中页面设计成tab形式，而tab的切换原始就是通过变换url实现的，后期为了支持popupAction才增加了通过actionName做跳转。

所以当时有过一种想法就是不要再有什么er.locator.redirect(this.tabs[index].location);这种直接修改location的操作，而是提供一个通用的方法，然后通过判断Action是子还是父来在Controller中做分发处理。至于如何判断一个Action是子还是父，则可以在创建Action的时候传入相应的标志。

[otakustay]

我的设想是这样的：

• 对于URL这事，现在的ER框架中，在Action里this.model.get('url')是可以取到当前关联的URL的，而且这个URL不一定和地址栏上的一样，是真正 进入到这个Action 时的URL，因此 isModify 这样的判断可以不用location.hash了
• 对于重定向，有一个办法是给Action.prototype加一个redirect方法，当controller发现是子Action的时候，会把这个方法重写掉，不过这个方法从框架的结构上来说不那么舒服，是不是足够合理请更多人一起讨论下

[otakustay]

在 2c6f7c1 中添加了该功能，后续再开放一段时间供大家讨论实现是否满足需求

具体可结合 #27 进行讨论

[errorrik]

对于URL这事，现在的ER框架中，在Action里this.model.get('url')是可以取到当前关联的URL的，而且这个URL不一定和地址栏上的一样，是真正 进入到这个Action 时的URL，因此 isModify 这样的判断可以不用location.hash了

我觉得url信息应该直接扔在Action实例里，放model里貌似有点不搭调

[errorrik]

er.locator.redirect

其实我一直不建议在Action里使用这个接口的。唯一麻烦的就是a了。是否需要接管a，preventDefault掉？在container上接管是否可行。

还有上次讲到的，要不要自动给container绑定click，提供command

[otakustay]

分2方面说这个问题：

首先，ER 3.0的设计是，普通的对象（只要有enter方法）都能成为Action。这个设计的目的是为了让ER可以用于非常简单的页面构建（非单页大型应用），但带来的一个问题就是，有可能使用者会用一个单例的对象当Action用。那么如果往这个单例的对象上丢东西，会导致对象的状态被外部修改，与其它的逻辑冲突等，因此仅会在调用enter的时候传递，而enter方法的参数设定为只有一个model，这也是为了保持接口的简单，所以url天生被放在model中。

另一方面来说，Action是一些逻辑的集合，应该是非常纯粹的普通对象。从这个角度理解，我不认为URL这一类与Web有明显关联的东西是Action的一部分

[otakustay]

其实我一直不建议在Action里使用这个接口的。

如果没有这个接口，在代码中进行跳转，会用require('er/locator').redirect(url)，那么怎么使locator的redirect可以形成正确的行为，不去修改地址栏，是个很复杂的设计。 @errorrik 有什么想法吗？

是否需要接管a，preventDefault掉

现在的实现就是这样的，会接管掉所有href以 # 起头的<a>元素并取消默认行为，转到controller上。

自动给container绑定click，提供command

这个command作何理解？我的设想中renderChildAction就应该是自治透明的，不应该再让业务开发者 因为是子Action所以要做些额外的工作 ，也保证一个Action可以同时作为主Action和子Action复用。

[otakustay]

ER最初的设计里是有一个Request对象的，里面会包含url、referrer、redirect等一堆东西，但由于加入这个东西导致ER在整个模型上会复杂一些（比如写个Action还要一会儿model一会儿request），所以去掉了，导致现在一部分在model里，一部分在Action自己身上，要加回去倒也不难……

[errorrik]

如果没有这个接口，在代码中进行跳转，会用require('er/locator').redirect(url)，那么怎么使locator的redirect可以形成正确的行为，不去修改地址栏，是个很复杂的设计。 @errorrik 有什么想法吗？

我没表达清楚。是不建议使用locator的redirect，因为用的会很脏到最后。当然，用action上的redirect就没问题

这个command作何理解？我的设想中renderChildAction就应该是自治透明的，不应该再让业务开发者 因为是子Action所以要做些额外的工作 ，也保证一个Action可以同时作为主Action和子Action复用。

这个话题有点跳跃，和当前issue讲的renderChildAction无关。

就是view提供一个事件叫做command，当点击元素带有data-command时，fire这个事件。最常见的外围dom点击事件代理。我们上次讨论这个话题是因为table内部有些单元格内的元素，点击还要有行为，拼接html比较脏

[errorrik]

另一方面来说，Action是一些逻辑的集合，应该是非常纯粹的普通对象。从这个角度理解，我不认为URL这一类与Web有明显关联的东西是Action的一部分

确实，Action本身是不需要管这些东西的。但是，Action也是有环境的。这个有点类似我们之前说的viewContext了。

[otakustay]

我们上次讨论这个话题是因为table内部有些单元格内的元素，点击还要有行为，拼接html比较脏

记起来了……DAN的Table已经被我这么搞了，不过以前的ER没有这么强封装性的View，所以command丢在Action上了。

View提供command事件是比较好的，但做通用比较难。难点在于，事件触发的时候，应该传怎么样的参数。反正不能直接把DOM元素丢出去……

如果是业务对应的View自身实现command事件，那么可以有逻辑去取一些东西，比如取一个data-id的值算id，或者向上找到<tr>取上面的id再substring处理之类的……但是在基类中做通用的话，这个command事件就只能传一个事件名了……除非设计一套语法来支持传参，比如data-command="remove(id=${id})"，然后View来解析……

[errorrik]

或者，直接取data-的，拼成Object，丢出去。。。

[otakustay]

确实，Action本身是不需要管这些东西的。但是，Action也是有环境的。这个有点类似我们之前说的viewContext了。

所以以前确实是有个叫Context，你也知道这版本的ER的设计很多是借鉴我在11年初的某个博客来的，当时有个Request对象，还有Session和Application这几级的数据管理。后来觉得ER核心应该精简些，Session管理和Application级静态数据并不是每个系统（不仅仅考虑ECOM内部的业务端）都会有的，所以去掉了。

去掉了以后一看，URL中的query参数本身就会进Model这个是没意见的，那么真的只剩下一个URL了，于是这东西就被我去掉了。

我现在想了一个解决方案：

考虑到单例对象当Action的问题，controller层面不变动，依旧在调用enter时把URL作为context一部分传递。Action基类里处理context的时候，把url拿出来作为自己的属性。

这样影响面仅在使用ER的Action基类时出现，其它不变，另外model中依旧还有url存在，用不用无所谓，不特地去掉了。

[errorrik]

嗯，没有contxt这个东西存在也没什么，我唯一比较质疑的是url直接放在model中。因为，如果query参数本身可能有url项。

[otakustay]

或者，直接取data-的，拼成Object，丢出去。。。

那么我们按ESUI的方式设计一套，弄成data-command-xxx="yyy"会变成xxx属性值为yyy，这样如何？data-*用得太频繁了，甚至一些jQuery插件之类的都要用到，不适合直接用。

只不过依旧感觉有点奇怪，ER最多的使用方式是和ESUI结合，那么ESUI会屏蔽掉DOM，ER的View不应该访问DOM，形成一个Actio->View->Control->DOM的隔离层，这里的command就没用了，必须由Control来提供。甚至产生一个副作用是Control完成command功能后，得preventDefault()掉，不然ER的VIew又会收到command，形成错乱。

[errorrik]

只不过依旧感觉有点奇怪，ER最多的使用方式是和ESUI结合，那么ESUI会屏蔽掉DOM，ER的View不应该访问DOM，形成一个Actio->View->Control->DOM的隔离层，这里的command就没用了，必须由Control来提供。甚至产生一个副作用是Control完成command功能后，得preventDefault()掉，不然ER的VIew又会收到command，形成错乱。

要不，就不默认提供了，在ESUI的Panel提供也行。我就是突然想到这事情，就抛出来，免得忘记了

[errorrik]

你的blog，现在改win8风了。。。

[otakustay]

Blog因为有一次服务器丢失，数据全毁，完全重新做过了，后台都是自己写的……

要不，就不默认提供了，在ESUI的Panel提供也行。我就是突然想到这事情，就抛出来，免得忘记了

我觉得Control可以直接提供command功能了，至少Panel、Label、Table、Tip这些全是会用上这功能的

我最初的想法是command纯粹应该是ESUI的一个Extension，Control都不用管这事，扩展挂上就有，不挂没有，需要的就全局挂一个

[errorrik]

我觉得Control可以直接提供command功能了，至少Panel、Label、Table、Tip这些全是会用上这功能的

上次讨论貌似因为不是全部控件都有视图，不是所有控件都会用到，所以把click给干掉了来着

[errorrik]

所以，就extension吧。其实这事，有感觉的人怎么都能解决，否则你告诉人有extension，人也不会用这货来解决的。如果你觉得需要，就在esui里默认提供一个extension好了～

[errorrik]

话说，重新写后台这种事情，现在真心没力气干了，老了。。。电脑没电了，回头再来看讨论

[otakustay]

已在 c733929 中将bindFn修改为bind

[otakustay]

嗯，没有contxt这个东西存在也没什么，我唯一比较质疑的是url直接放在model中。因为，如果query参数本身可能有url项。

我回顾了一下现在的实现，如果query中有url这个参数的话， 会覆盖 掉model中的url。

不过默认的Action基类，会把enter时传入的参数保存起来，所以可以在Action中用this.context.url取得真正的url，其它包括this.context.isChildAction也可以取到（虽然model中也有），是不是还有必要把url放到Action下方便用this.url取呢？

[killeryyl]

renderChildAction 里 配合 hijack 后会出现这样的情况：
点childAction的a标签刷新childAction时，containerhijack没有消失，造成hijack 事件在container上多次绑定。

另外，这个refresh的概念还是考虑下吧。
这个场景，childAction的view里有搜索按钮和搜索框，点按钮后，当前childAction得刷新下，但是当前视图的有些值，比如container，isChildAction等非model里的数据还是要的，而model里初始数据则由类似enter(context)的context传递过去。

[otakustay]

我原先的想法是在重定向的时候，Action本身会放leave事件，enterChildAction在leave事件里有注册函数取消掉hijack功能。当时确实思考过如果Action是用户自己写的对象没有这事件怎么办，我再去仔细看看吧。

refresh这事容我再细想一下，因为从框架层面上，其实真的不太知道哪些东西要refresh，可能有点麻烦，我会近期下个结论，其他人也可以讨论下

[otakustay]

在 248fa97 中增加了一些代码，保证去除hijack事件处理函数的覆盖面更全。

关于refresh这个问题，还是没想得太明白，能从逻辑上来讲一下你对这个接口的要求吗，比如这样：

Action需要一个refresh接口，这个接口与现有的enter的区别是balabalabala，在其中会做的操作有balabalabala……

[killeryyl]

Action refersh接口需求：
第一次进入使用enter，事A是给container绑定或委托一些事件以及Action自身绑定一些事件，特别是如$(container).on('click','.subClass',function(){})这样类型的，事B是给container里面的事情绑定事件或做一些Model的转义等等操作。此时Action需要自己刷新一下，包括Model的重新获取以及View的重新渲染，那A事件就不运行了，B要运行的。如果没有refresh的话，我只能这么弄了,controller.renderChildAction('actionpath',action.view.container, args)。。。 自己调用renderChildAction刷新自己，感觉很怪，自己变成自己崽子了。

[otakustay]

事A给container绑定事件是在View中做的，Action中不会有直接绑定DOM事件的代码。那么在refresh的过程中，View是销毁后重新创建并render()，还是保留原来的View实例只是再次调用render()？根据这个选择的不同，会产生 不同的实现：

• 如果View销毁重建，再调用render()，即完整走createView() -> render()这过程，那么不存在 事A不用做 的问题，因为View销毁的时候会把container上的事件都注销，重建并渲染的时候再绑回去，这个流程和正常的enter()完全一致。
• 如果保留View的实例，那么流程是model.load() -> view.render()，跳过createModel()和createView()这两个过程，则要在View上添加一个repaint之类的方法，Action再添加refresh之类的方法。不过因为这个refresh事实上就是重做model加载和view渲染，感觉是一个更贴近具体业务的东西，是否合适做统一的提供依旧持怀疑态度。

给Action自身绑事件这个事我依旧想强调，不应该出现 给自己绑事件 这样的行为，这不是事件的正确用法。

ER所推荐的做法是，当有参数改变时，这些参数要表现在URL中，这是ER对 可访问性 的追求，也是ER的最初、最核心的理念，另外ER的理念还有 模板保持无JS依旧基本可用 等。如果参数不在URL中，就不能通过复制URL分享当前的页面，会违背ER的理念。

如果当参数变化时，参数会在URL中，那么代码应该是this.redirect('newactionpath')即可，不需要调用controller.renderChildAction

[otakustay]

到现在为止看起来这功能圆满了，先关掉，有事再开~