增加一个 ControlProvider工厂获取控件类

[Exodia]

在我们的业务端模块中，经常出现 require('ub-ria-ui/xxxConrol'), require('ub-ria/xxxControl');

而 ub-ria-ui 和 ub-ria 的控件又经常变动，当这些控件变化时，需要更改ub-ria/tpl.js，同时也要更改业务端模块的这些路径，这对业务端透明升级带来了部分麻烦，一个很实际的场景就是 selector 系列的控件路径变了，而业务端有控件继承此类控件，导致了需要变更代码，希望提供 ControlProvider 单例类来解决这样的问题。

大概业务端对控件的依赖会变成这样：

var controlProvider = require('ub-ria/controlProvider');
var TableRichSelector = controlProvider.get('TableRichSelector');
var exports = {};

var CustomControl = reuqire('eoo').create(TableRichSelector, exports);
return CustomControl;

同时 View 层的代码也不需要显示的加载对具体控件的依赖，仅仅require('ub-ria/controlProvider')即可。

[otakustay]

这会导致AMD的依赖关系丢失了，那么我们在哪里去保证TableRichSelector一定在CustomControl之前得到加载？

[Exodia]

controlProvider.js 中会加载所有的控件

[Exodia]

当然这会导致所有控件都加载进来，不清楚是否有业务端只需要其中一部分控件

[otakustay]

controlProvider.js 中会加载所有的控件

确认这不会导致controlProvider.get变成一个异步的方法？

或者你是打算在controlProvider里显式地require所有控件吗？

[Exodia]

我打算显示 require- -

[otakustay]

我对这个事比较犹豫了，我的主要考虑是这样的：

1. 我们的问题是一个内部的问题，但我们没有在内部消化，却对外造成了影响（不需要的组件被加载了）
2. 这会导致我们没办法让2个同type的控件同时存在并且根据系统2选1，比如你的ub-ria-sidebar也放进controlProvider里的话就会直接出错了
3. 如果按这么来，我们会有多少个controlProvider呢？系统里是不是会有一个继承ub-ria的controlProvider来额外再把业务控件引过来呢

所以总得来说我不支持这个玩法

从长远来看，你提的肯定不是一个最完善的解决办法，比如在不直接需要父类型（比如我用super()就不会直接需要父类型）的前提下，我可以把esui的整个流程init打造成异步的，并增加async esui.define(Constructor, parentType)的方法，和init结合一起能对外也没有影响地解决问题。当然我现在没想清楚只是说说大概的，init的异步化是早晚得做的事情