为了复用模块需要做的变更

[otakustay]

为了复用模块需要做的变更

[otakustay]

现在比较棘手的是第2点权限的问题，各位有啥想法没有……

[otakustay]

还有FormModel中的rule事实上也应该不同项目区分开来

[srhb18]

现在比较棘手的是第2点权限的问题，各位有啥想法没有……

模块本身使用的权限名称允许在一个相对独立的地方做映射？

比如：AD模块里依赖ADM系统下的CLB_AD_VIEW权限，这个权限在AD模块里其实是canViewAD，在模块配置config里对CLB_AD_VIEW和canViewAD单独做一个映射，考虑到1中所说的config不打包走，这样当AD模块在SSP系统里用的时候，就可以根据SSP系统里的config来给canViewAD映射SSP系统中的权限了

[otakustay]

嗯，首先canViewAd对应CLB_AD_VIEW这个如果在Model的实现中写死，那就没办法映射了，要映射就要继承Model整个给换掉

所以 映射 一个正确的方向，关键在于怎么去设计出程序结构，来支持这种映射，你说的是通过config来做喽……

我这边的一个想法是加个PermissionProvider，类似于Data的效果，但又为啥不叫PermissionData呢……所以这些就比较纠结了

[srhb18]

其实我一直有一个想法，及时是最大程度的复用，在两个异构系统里也是多少会需要一些适配的，看到你说config不打包走的瞬间，我就想把config作为一个适配配置器来用了，就好像我们的模块是一个SataII接口的硬盘，如果系统是IDE的，就需要这么一个转换器了；

另外，考虑到Action拿config的配置相对容易，改动也会小一下，config又是在系统加载的时候就执行完成的，不会导致什么顺序问题，所以我建议用config做适配

我这边的一个想法是加个PermissionProvider，类似于Data的效果

PermissionProvider这个东西感觉也可以，因为本身权限在使用的时候就是被抽象成了Model了，Data-->Model也很自然，但是就是有一个问题，这东西是一个全局的还是模块内的，如果是模块内的，又如何来屏蔽系统的权限异构问题？

[otakustay]

config不打包的原因很简单，config一加载就把URL配置上了，这不是我们想要的结果……

适配配置器这东西，理想来说，是IoC，不会是config哦，你试想下有IoC存在的情况下会怎么来～

[srhb18]

刚刚和@Exodia在茶水间讨论了一下，有IOC以后，datasource可以直接用canXXX: permission('canXXX')

然后靠Ioc引入不同的permission配置来实现异构，某个permission的配置可能就是：
A系统：
permission: { value: { canXXX: 'CLB_XXX' }}

B系统就可以是：
permission: { value: { canXXX: 'SSP_XXX' }}

[otakustay]

permission是datasource上的一个函数，datasource是单例的，因此如果不改变这个现状，就不能指望IoC来改写datasource.permission，这里会有并发干扰的问题（虽然99.9%的情况下不存在并发干扰）

因此我的想法就是canXxx: this.permission.has('XXX')，permission是挂在实例上的一个对象，是多例的，IoC就能配置