很多时候在app团队作业时候会有这样的场景：
- server 端小伙伴总是很忙，总是不愿意配合我们该接口
- 我们客户端总需要重复搭建各类表单／表单型展示页，每次都要在代码里改datasource，改model等麻烦的事，哪怕框架共通写的再好也要面对重复的代码发呆
如果server的api返回的就是这样的数据，那说明你遭遇的是正常待遇，那如果你说，唉？不对啊，我们有特地为app服务的专属server团队，那...你可以直接拉到下面看～
每当遇到这样的场景，遭受正常待遇的我们总会想到设计下面这样个model：
<pre>struct Person
{
var id : String!
var name : String!
var salary : Double = 0
var summary : String!
var description : String!
var displayedDiscription : String {
return "PersonId : \(id) \n Description : \(description)"
}
var displayedSalary : String {
return currencyGenerator(currencyDoubleValue: salary)
}
func currencyGenerator(currencyDoubleValue : Double) -> String
{
return ""
}
init(json : [String : Any]) {
}
}</pre>
然后为了完成上面右边的View的需求，我们会见个tableview，然后为这个亲爱的tableview做个特殊的datasource，比如这样：
<pre>func setupData() -> [String : Any]
{
let sampleSource = ["id" : "10000", "name" : "Fish", "salary" : 5000 , "summary" : "fff", "description" : "sss"] as [String : Any]
let person = Person(json : sampleSource)
return ["Name" : person.name,
"Salary" : person.displayedSalary ,
"Summary" : person.summary ,
"Desciprtion" : person.displayedDiscription]
}</pre>
后续的就不看了，大家也都猜得出。
我们辛辛苦苦做完了，上线了结果隔壁产品同学说，
呀，我们想加个字段，加一行手机号之类的东西，
呀，我们还想拿掉那个summary，感觉没什么用，
哎呀呀，我们还要调整个顺序，把Salary放到最下面...
呀呀呀，呀你妹啊 T_T 你以为这改动很简单么，要加字段，要加xxx，要发版本上appstore...
那回过头想想每次这样做，我们的心会不会很累？可能server 端的同学会觉得这就是我们要做的事，可是重复写这些code，每次要改那么多分散的地方，我们会不会很累？我们不觉得累，我们的xcode都会累呢。
所以我们静下心来看下上面那个View，其实我们可以在每行都找到共通特征：
比如左边有个title，右边有个value，
那我们是不是可以有个Row的对象，里面有2个属性：key和value，
key就是左边显示的文案，value是动态变化的
所以有了这样的对象：
<pre>struct ConfigRow
{
// left title
var key : String!
// right title
var value : String!
}</pre>
那是不是如果我们有了5个这样的对象，就能满足上面那个View里的结果了呢，当然你可以选择创建5个ConfigRow，然后凑成个数组作为datasource。但是这个做法，依旧很笨，依旧要改代码；
这时候，传说中的plist就要登场了，
我们是不是可以把这5个对象放在plist中，然后做一系列反序列化的方法把plist构建成我们要的数组datasource是不是就好了呢？因为这一系列方法肯定是共通的，所以每次做新类似内容，我们只需要建立个新的plist，然后调用共通方法构建datasource，然后调用应该已经可能被共通抽离出来的tableview构建方法，这样就能完成这样个简单模块的编写了。
最重要的是，每次有文案修改，你只需要修改plist中内容就行了，这样哪怕是别的不是负责你这个模块的开发者来协助，他也能很快完成，毕竟字他总认识～
但是，我们需要对上面的Row进行下扩展，我们还需要加上颜色和排序的属性，来随意控制相应的属性：
<pre>struct ConfigRow
{
// left title
var key : String!
// right title
var value : String!
var sortOrder : Int = 0
var color : String = ""
}</pre>
当然你还可以新增别的，比如左边title的样式属性，右边的value的样式属性等等等。
这样，一个白板就构建完了，我们的tableView上已经华丽的自动出现了那些固定文案，比如左侧的所有label，或者顺序／颜色；但是，最重要的右边文案从哪来填充呢？
这里提供个最简单的path方式，我们在plist中每个row的displayValue的默认值写成对应的json中的key值，比如name的displayValue就填value，然后在cell的设置row的方法中：
<pre>leftTitle.text = model.value(forKey : row.displayValue)</pre>
这样的思路就能解决白板填充的问题了，如果需要存下值的化，我们最终的ConfigRow可以变成这样：
<pre>struct ConfigRow
{
// left title
var key : String!
// right title
var value : String!
// json中对应的key值
var valuePath : String!
var sortOrder : Int = 0
var color : String = ""
}</pre>
valuePath就是我们可以写死的key值，而从json中获取来的数据可以塞到value中，这样保存着也方便以后用
再扩展下，比如这是个填写型表单页
也是一左一右的构造，只是右边是个输入框了，我们针对输入框做了一系列属性来控制，比如
- 右边框的样式，可能是输入，也可能是日历，也可能是选择，这些通过枚举后在共通框架中实现就行了
- 输入限制的正则表达式regex
- 输入框键盘的样式：数字／字母等
同时我们把单个Row的cell相应属性也抽到了plist中修改：
- cell的identifier重用标示，其实也就等于你可以指定当前Row用什么样的cell来显示
- cell的segue，因为我们用的是storyBoard跳转，所以可以通过segueIdentifier来直接在tableView的didSelect方法中进行跳转，当然别的跳转方式也可以支持哟，就看需求了
- cell的高度height，如果不需要自动计算的或者手动计算的话，我们直接把cell的高度也放在了ConfigRow中进行修改，这样controller中写死的东西又少了
当然还有别的功能就不一一列举了。
其实这一整套是很简答的思路设计，重点核心就是我们去掉了业务对象化的思路，而是采用了针对View的单行进行对象化，即原本纵向的考虑变成了横向，真正站在tableView的角度想他需要什么。
这样的设计可以把我们从修改代码的常规逻辑中抽离出来，其实每次我们只需要改相应的plist，也能完成看似很简单其实真的很简单的问题，何不尝试一下呢？
当然，之前提到，如果你有一个很好的专门服务的server服务团队，这套plist就可以放在服务端，这样他们也可以通过配置文件来直接配置表单了；而server端哪怕没有这个条件，我们也可以把这些配置放在我们工程中，这样每次开发时候也方便我们修改了。
当然，这期中最有问题的应该就是上面的valuePath这一段了，如果遇到复杂的需求需要同一个位置显示多个字段拼接的，比如：
Description = ID + Descprition
的显示该怎么办呢？
下期中会介绍专门为这个需求而诞生的工具 CodingForP，
https://github.com/SpiciedCrab/CodingForP
到时候我们就能明白这有多有趣了。
