Raw数据
shoeLastGenderAndFootTypeAndSize:{"男":{"EURO":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"UK":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"US":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"CM":[40.5,41,41.5,42,42.5,43,43.5,44,44.5]},"女":{"EURO":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"UK":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"US":[40.5,41,41.5,42,42.5,43,43.5,44,44.5],"CM":[40.5,41,41.5,42,42.5,43,43.5,44,44.5]}}
数据源
shoeLastGender
type:fixed
params:null
returnType:JList
returnValues:shoeLastGenderAndFootTypeAndSize.keys()
shoeLastFootType
type:fixed
params:
shoeLastGender JJString
returnType:JList
returnValues:shoeLastGenderAndFootTypeAndSize[shoeLastGender].keys()
shoeLastSize
type:fixed
params:
shoeLastGender JJString
shoeLastFootType JJString
returnType:JList
returnValues:shoeLastGenderAndFootTypeAndSize[shoeLastGender][shoeLastFootType]
表单编排
下拉框组件：
字段名称: 鞋楦男女
绑定的属性: shoeLastGender
数据源:
shoeLastGender
下拉框组件：
字段名称: 鞋楦脚型
绑定的属性: shoeLastFootType
数据源:
shoeLastFootType
params:
shoeLastGender: content.shoeLastGender
下拉框组件：
字段名称: 鞋楦码数
绑定的属性: shoeLastSize
数据源:
shoeLastSize
params:
shoeLastGender: content.shoeLastGender
shoeLastFootType: content.shoeLastGender
我的思考
目前我设计数据源的时候设计了一种类型为fixed的数据源，该数据源的适用场景是下拉菜单数据写死的场景。但是，我觉得这种方法会增加表单渲染器的开发难度，不如所有数据来源于服务端干净利索。不仅如此，该方案也会增加后端数据校验器的开发难度。
我认为创建表单、编辑表单并不是一件高频率的工作，我们让这个接口的所有数据源、检查器都从服务端获取数据，也并不是不可以接受。我的意思是，即使一个简单的男女的下拉选项，我们都从服务端获取，同时验证用户输入的是否为男女选项，我们也可以交给服务端验证。在我的记忆中，很久以前的Web开发，走的就是这样的一套流程，我们适当的返璞归真，可以更利于我们系统的设计。
谈到便利性，不得不谈一下用户理解这个东西的成本，fixed类型数据源虽然利用前端存储数据，减少了和后端的交互，但是它增加了用户的理解成本，学习成本，可能不利用推广。