页面配置

用MVC框架来开发WEB页面已经是非常成熟的一个事情，那为什么还需要用配置的方式来做页面？

1. 不需要应用发布、重启即可生效
2. 可以跨应用重复使用模块

在做的比较完善的情况下，产品跟你说一个需求，可能等他回到座位上的时候你已经做好了。当然并不是所有的页面都可以用配置来做，不然配置的方式会巨复杂无比：

1. 页面布局足够简单
2. 组件足够通用，能够重复利用
3. 数量足够多

报表是一个非常典型的场景，大家可能对报表这样的页面见到不是特别多，其实在运营后台、仓库管理系统页面非常非常非常多，如果配置能做够灵活，那么这部分的工作量就都可以省下来了。

那么，要实现一个页面配置需要解决哪些问题？

1. 布局
2. 组件重复使用
3. 交互
4. 预览
5. 业务应用接入

下面依次来看：

布局

经典的布局解决方案是栅格系统（bootstrap），其中的角色包括：

1. container
2. row
3. cloumn

比较牛逼的是可以嵌套，用到的技巧可以看这里，这样我们用这种方式实现比较复杂的表头的时候还是比较容易的! 让开发去写一大堆的class、div来做页面现在比较头大，那么现在的办法是：

用简洁的语法把页面需要展示的东西表达清楚，然后将其翻译成HTML+JS。

自己YY的一个语法如下：

@layout
    @layout
        @CompA // 条件
        @CompB // 条件
    @CompC // 查询
    @CompD // 导出
@CompE // 列表展示
@CompF // 分页

通过缩进来控制层次（或者归属）关系，通过@layout来统一控制一组组件的排列展示。

组件的重复利用

能够复用的组件可以是：展示+数据，在重复利用时只需要将其引入那么基本上什么都不用管了：

@import:easydt/warehouse_list // 引入仓库列表组件

引入之后展示就没有问题了，只需要考虑该组件如何与页面上其他的组件互动。

交互

我们要做的是一个动态的页面，静态页面的解决方案现在已经很多了，相比较动态页面要复杂很多：

1. 响应用户操作
2. 组件之间交互

用户的响应还比较简单，对于不同的控件可以预先实现不同的事件，在事件发生时触发对应的代码：

@CompA
    @on(click)
        alert("用户点击了按钮")

组件之间的交互有两种实现方式：

1. 暴露接口供其他组件调用
2. 事件驱动

第一种方式在MFC、Swing等编写的时候基本上都属于这种，感觉写起来太消耗脑细胞! 而且HTML的页面上各部分的交互数据居多，那么可以参考Actor模型来设计：

@channel(param)

@CompA(to = "param")
@CompB(to = "param")
@CompC(to = "param")

@CompD(from = "param")
    @on(click) // 响应点击事件
        // do sth.

在查询条件A、B、C发生变化时将结果发送消息给D，然后在D本地将其保存起来方便后面使用（比如发送请求）。

预览

在一个独立的页面配置应用上配置完成之后预览时，需要的数据要到业务应用中获取，用ajax的话就遇到了跨域问题。两种解决办法：

1. 所有的接口使用JSONP格式
2. 在业务系统中提供一个页面专门用来做预览

用JSONP的主要缺点就是只能用GET方式，也就是说：GET的限制JSONP全都有。第二种方法则有点像开个后门，直接看到的效果和在应用中看到的效果已经是一致的。

业务应用接入

接入的方式是由配置的产出的结果有关系的，现在有两种产出的方式：

1. 提供JSON接口来输出展示需要的数据
2. 根据配置动态生成JS文件

第一种方式比较直观，做起来也很简单，业务方执行的流程如下：

1. 开发写个页面将CODE设置进去
2. 渲染HTML页面，然后运行JS根据CODE去获取展示所需的数据
3. 渲染页面

该方式有个小小的问题：在根据CODE获取页面时页面会出现空白。用第二种方式将生成的JS引入对应的页面即可，具体页面长什么样子都在该JS文件中保存。这样做的好处是：

1. 可以在JS文件中定义更加复杂的操作
2. JS代码在浏览器做缓存，从第二次操作开始就不需要请求页面展示的数据

另外在产出JS时基本上就没有搞不定的事情了。

总结

其实这个还没开始做，想法也在UPDATING，做完再来总结:)