基础概念
组件
我不是很擅长阐述一个东西，所以我截取了金数据中我认为应该是一个组件的截图：
同样的，在我们的项目中，如下截图也应该为一个组件：
考虑到我们项目目前的动态表单的需求，我在第一阶段准备开发如下组件：
- 文本输入框（前后端支持非空、长度、整数、小数、小数位数、数范围校验）
- 单选下拉框（前后端支持非空、值是否属于正确范围校验）
- 多选下拉框（前后端支持非空、值是否属于正确范围校验）
- 二级联动下拉框（前后端支持非空、值是否属于正确范围校验）
- 三级联动下拉框（前后端支持非空、值是否属于正确范围校验）
数据源
数据源是个什么东西呢？单选下拉框需要显示一些下拉项，目前的常规实现方法大概有两种：一种是前端写死在代码中，一种是从服务端获取。
在我的方案中，这些数据都将从服务端获取（避免过度设计，同时便于用户理解，可以在看完所有设计后再讨论这个问题），我们将这些提供下拉项数据的接口称做数据源。我们通过为同一个组件切换不同的数据源，从而可以使这个组件显示不同的下拉项。
当然，我既然已经提到了数据源的概念，那么可想而知，我们一定是对提供数据的接口进行了一定的包装。我会将这些东西体现在我的详细设计中。
检查器
前端在用户完成一个文本框的数据后，需要进行检查。后端在入库后，同样也需要进行输入检查；不同的数据源应该也搭配不同的输入检查器，如何实现统一呢？
针对常规的检查（及不需要与服务端进行交互的检查），前后端各自独立的进行检查，只需要相同输入检查结果一致即可。针对需要与服务端进行交互的检查，我们通过检查源的概念实现服务端和前端检查方式统一。
针对常规的检查，检查源就是一段正则表达式；针对与服务端交互的检查，我们的检查源其实是一个接口，前后端的处理逻辑相同，都是将数据按照这个接口声明的方式传递给这个接口，从而实现校验效果。
同样的，检查器也是对提供检查功能的Url的包装，具体细节，我会体现在我的详细设计中。
高级概念
rawData
为什么会有rawData概念的存在呢？想一想，我们将所有的下拉项都通过后端的接口提供了，后端的工作量有多大？如果用户需要临时调整某个下拉项里的项，我们至少还得为他修改配置文件，从而实现这个改动，这样实在是太低效了。
我推出了rawData的概念，rawData就是一段json，用户将json提交到后台，我们解析这段json，判断这个json的结构是否符合我们的预设，如果属于的话，我们将自动为用户生成相应的数据源和检查器。因为我目前的设计是针对公司内部用户的，我不会假设我的用户不理解什么是json（如果不理解，我觉得我应该有办法教会他）。
用户可以随时修改rawData，这些修改会立即体现到各个表单上。当然修改json影响到了数据结构是不允许的，除非目前没有表单正在使用当前的rawData生成的数据源。
如果未来我们的动态表单将会面向普通用户，我是支持开发一个简单的rawData编辑器的，我无所谓，因为对我后端来说我都是存rawData，并且自动生成rawData数据源和rawData检查源。有时候用户体验真的很重要，我会在阶段三后将该功能纳入开发计划。
这一期我支持的rawData结构有：
# 适用于简单的下拉框
["","",""]
# 适用于二级联动的下拉框
{
"":[]
"":[],
"":[],
}
# 适用于三级联动的下拉框
{
"":{
"":[]
"":[]
"":[]
},
"":{
"":[]
"":[]
"":[]
}
}
rawData数据源
rawData就是在用户提交了json后，自动生成的接口（其实不是接口，而是一个通用的接口可以出相应的rawData数据，会体现在详细设计中）及相应的数据库记录。这个东西的存在，是为了简化开发任务的，同时为了能够快速相应用户的需求。
rawData检查器
rawData检查器同rawData数据源。
表单上下文
表单上下文，存在的价值是什么呢？是为了实现组件间的联动，假如一个只声明了一个属性的组件，却绑定了需要两个参数的数据源，这个意味着什么呢？意味着我们的这个组件根本就无法提供足够的参数去查询这个组件需要的数据，那我们该如何处理呢？我们需要从表单的上下文，再获取一个参数，然后绑定到这个数据源的参数上。哈哈，其实这就实现了联动的效果。
实际上，我做了很多便于理解的设计，让我们的组件复用性提高，这就是表单上下文存在的价值，通过表单上下文，我们能够实现组件间的联动。
组件上下文
为什么我又提出了组件上下文的概念呢？组件上下文中只包含当前组件声明的属性，这主要是为了方便用户为数据源绑定参数。这些我都会在设计细节上体现。
系统整体构成
系统整体由这些部分构成：
数据源接口、检查器接口、rawData数据源接口、rawData检查器接口
各个服务提供数据源、检查源的接口，这个是很好理解的。rawData数据源和检查源接口，这个也是很好理解的，就是一个接口，用户传递什么参数，我们就返回什么值。
检查器管理系统
叫做管理系统，实际上是开玩笑的，它仅仅就是用来包装这些检查器接口的页面，我将检查器分为了三种类型：
- rawData检查器：就是有rawData自动生成的检查器（向检查器表插入了记录）。
- 基础检查器：就是一些可以通过正则完成检查的检查器。
- 定制检查器，就是需要和服务端进行交互的检查器。
接口请求数据，往往是需要传递参数的，所以我们我们的检查器同样有参数的概念。我简单的设计的添加检查器的页面如下：
检查器管理系统是高度服务于开发人员的，所以我需要测试无处不在，故我为每条条目设计了如下的选项卡：
另外，检查器接口的错误码需要高度定制化，我发现我们目前的系统没有一套优雅的、全局的错误码处理方案，这个对我来说非常的尴尬，我必须想办法处理好这个问题。
检查器管理系统可以新增、查看管理器，删除、修改、都必须在管理器未被使用的情况下进行。另外值得说明的是，检查器管理系统应该只有开发具有权限操作。
数据源管理系统
数据源管理系统和检查器管理系统几乎一致，我这儿不想再赘述了。
属性库、名词库
这个是为了国际化的
组件库
这个也是为了方便我们开发调试的。同时也可以向用户展示我们组件库的效果。
表单设计器
这个是重中之中
rawData管理系统
单纯的一个json数据管理系统，其实没有多复杂的。