【ub-ria升级需求汇总】取消“抽屉弹出”的强制交互

[DDDBear]

现行的ub-ria版本，列表以及表单中多处（列表中’新建’，列表表格内’读’，’写’，’复制’；表单的内嵌表单） 出现强制“抽屉弹出”方式的交互。考虑到某些项目场景下，并不需要此种交互效果，因此考虑将“强制”改为“可配置”。

提供一个参考修改方式：使用“组合配置”的方式，类似目前SubmitHandler的处理。

大家有什么其他的好建议也可在此讨论。

[otakustay]

这个交互如主题所说用在很多地方，所以我最初想的FormOpener显然不是一个合适的名字，我们得有个名字，然后定下接口

接口我觉得比较简单，最基本有一个open(url, options)就行了，或者open应该叫forwardTo之类的也行

随后为了配合像抽屉之类的这种情况，要有一个类似window对象的抽象（我在ER4.0里会有这个东西，计划是叫Container的），上面有基本的hide、dispose等方法，无论是直接跳转还是用抽屉还是用Dialog，统一都返回实现这样一个接口的对象

[DDDBear]

个人认为，那些使用drawer的交互的地方升级后应该分别使用独立的handler做处理，因为很有可能出现新建要使用跳转，表格内修改要使用“抽屉弹层”这种分场景的需求。独立出来的handler可以在项目端自行指定实现（抽屉，跳转或者Dialog），一个实现可以被多个handler使用。

每个实现里统一有一个接口，我感觉就叫handle挺好的，其余的无论是open还是forwardTo其实都隐含了某种形式。至于hide和dispose方法，我觉着都是控件的内部实现，无需硬性指定。

[otakustay]

接口还要考虑与原页面之间的数据传递，比如子表单新建的内容要么父表单上

我们的接口只能选择包含所有可能的交互的全集来抽象，选择交集的话会造成有些场景无法处理，所以我认为得有hide和dispose

在 2015年7月13日，下午3:30，DDDBear notifications@github.com 写道：

个人认为，那些使用drawer的交互的地方升级后应该分别使用独立的handler做处理，因为很有可能出现新建要使用跳转，表格内修改要使用“抽屉弹层”这种分场景的需求。独立出来的handler可以在项目端自行指定实现（抽屉，跳转或者Dialog），一个实现可以被多个handler使用。

每个实现里统一有一个接口，我感觉就叫handle挺好的，其余的无论是open还是forwardTo其实都隐含了某种形式。至于hide和dispose方法，我觉着都是控件的内部实现，无需硬性指定。

— Reply to this email directly or view it on GitHub.

[otakustay]

另外：

1. handle这名字实在不明所已，handle的是啥
2. 这个接口本身的名字到底应该叫啥依旧不知道，我理解不同场景都要有一个实例来处理，但他们的接口应该是一样的，某些程度上也复用同一个类，那这个接口叫啥

或者说，有另一种做法：

1. 本身页面不对这些事件做处理
2. 加一堆plugin来搞这些，要的就拿plugin上，不要的丢

但这个做法存在的问题是太麻烦，一个plugin横跨action、view、model，得有好多组合，同时也和我们规划的未来的Feature模型相似度太高

所以还是想想接口的名字算了

[DDDBear]

我也倾向使用接口，名字的话，execute呢，不具体说执行的方式是出于_方式是不定的_的考虑。

接口还要考虑与原页面之间的数据传递，比如子表单新建的内容要么父表单上...所以我认为得有hide和dispose

关于这点，不知道我理解的场景对不对。内嵌Drawer被关闭后可能需要传递数据到父表单，此时使用事件的方式通知父表单，父表单完成处理后，* 主动 * 调用hide接口执行特定实例的相关关闭操作？因为在我理解，接口释放出来的一个作用就是被重写和调用的。

[otakustay]

方法名称的话，我原来想的这无非是“从当前页面去另一个页面做事”，所以用了forward这个词了，不合适的话慢慢想

不过类的名字最难想……

内嵌Drawer被关闭后可能需要传递数据到父表单，此时使用事件的方式通知父表单

所以这个事我们怎么去抽象出来，在不确定是Drawer或者不是的时候，怎么传递数据？设定一个接口并拥有有关的事件吗？

[DDDBear]

所以这个事我们怎么去抽象出来，在不确定是Drawer或者不是的时候，怎么传递数据？设定一个接口并拥有有关的事件吗？

嗯，我觉着就是事件。但是事件名不是原来的close啥的，我觉着叫leave就行了吧，跟forward那个接口对应起来。

[otakustay]

我们能总结下现在ssp这边和抽屉有多少种交互，有多少事件（包括抽屉自己的+里面action的），来做一个参考不

[DDDBear]

ListView中drawer有关的事件

            // 抽屉内Action提交取消时处理
            drawerActionPanel.on('action@submitcancel', cancel);

            // 抽屉内Action点击返回时处理（一般是只读页）
            drawerActionPanel.on('action@back', back);

            // 抽屉内Action的内嵌Action点击关闭时处理
            drawerActionPanel.on('action@saveandclose', saveAndClose);

            // 抽屉点击关闭时处理
            drawerActionPanel.on('close', closeDrawerActionPanel, this);

FormView:

            drawerActionPanel.on('close', saveAndClose, this);
            drawerActionPanel.on(
                'action@entitysave',
                function (e) {
                    saveRelatedEntity.call(this, e, targetId);
                },
                this
            );
            drawerActionPanel.on('action@handlefinish', handleAfterRelatedEntitySaved, this);
            drawerActionPanel.on('action@submitcancel', cancel);
            drawerActionPanel.on('action@back', back, this);

个人感觉这部分逻辑有点儿乱，List和Form中有交叉的事件也有不同的事件，可能需要重新整理下，并且如果确实有所差异，可能handler的实现需要 “展现形式” + “展示内容”两个维度的组合。

[otakustay]

看起来把加载的Action丢出来，自身再有个leave之类的事件就可以了的样子

[DDDBear]

嗯，action丢出来是个好办法。其余的就是handler自己的事件了。我嚼着就可以了。

[otakustay]

其他人还有建议么，没有的话我们按此执行好了？