关于Json解析：

现在很多工具都提供了将实体类转化为Json字符串的功能，而且相当一部分都具备“用注解告诉你这个值不要解析到json中去”的能力。

然而，必须注意到，这种工作是在代码中敲死的，或者即使说用配置文件可以动态的修改，修改它也将是一场灾难。

因此提出一种json解析语法，可以通过接近于原生json串的文本描述json返回格式，以此决定究竟怎么去解析它。

采用json解析语法有什么好处：

json串可以实现系统间轻量级信息交互、通讯，是平台无关的。然而工作中的一个实体类往往含有大量的不相干数据，假如一股脑解析到json串中，轻则数据冗余，交互性能下降，重则机密数据暴露，在此略过一千字。然而，通过码农的代码对最终json串中的数据进行控制是非常糟糕的，因为这需要做很多不必要的工作。

而json解析语法的作用就是将“json返回什么”从程序中抽离出来，通过修订语法文本，你完全不需要修改源程序，只要建立一个后台管理页面，就可以实施完成这件事情了。

基本语法：

关键词：_bean。作用：_bean代表了当前传入的，将要被解析的任何一个Object类型。

语法：:_bean{a,b,c}。作用：有选择的解析这个_bean。将会解析_bean下的a,b,c三个属性，并用属性名作为json串的key

瞧，就这么一个简单的结构，就完成了原来需要做的”把bean中的a,b,c单独提出来放到一个Map中然后对Map进行解析“这么个操作。

但假如就这点本事，那就称不上是一个规范了。

语法：_bean{name:a}。作用：解析a这个属性，然后用name作为它在json串中的key

嗯，虽然一般来说这并不必要，不过这种事情谁说的准呢？

语法：_bean.a。作用：就是大家最熟悉的语法，从_bean中获取属性a，如果后面没有大括号的话，大概就会直接解析掉啦

关键词扩展：

虽然该规范侵占的唯一一个单词是_bean,不过实际工作的话可能需要更多，假如有一些属性比如_bean.a.b[0].c非常常用，那么你并不需要每次都这样打点调用

可以声明一个自定义的占用单词，假定它是_ccc，那就可以直接写_ccc获取到这个属性。

可以预见的是，这个东西可以将”json该返回什么数据“与程序员完全剥离开来，甚至可以找一个完全不懂编程的人来编写，只要他知道”业务A的接口需要返回这一大堆东西，业务B的需要返回这一大堆。哦，今天老板说业务A的返回内容要精简，把这个干掉就好“

当然，我的描述一塌糊涂，并且可能看到现在你也不知道我想说啥。

所以我就把目前为止想到的完整规范贴在下面，反正我还是说不清楚=_=

基本语法：

_bean

（扩展：定义_url等预定义资源信息）

_bean{a}

_bean{name:a}

_bean{"name":a}

_bean{a[1-1]}

增强语法：

_bean{a[-1@{b,c}]}

${}获取自定义资源

%每次都获取资源最新信息

#注释

_bean{${}}在bean结构中嵌套插入自定义资源（作为常量）

高阶语法：

_bean{a->funcName}跃接语句，将bean中的属性a作为参数传递给自定义扩展的funcName方法，并对返回的结果进行解析。跃接解析过程如果a的属性名以“id”结尾，则删除最后两位

_bean{name:a->funcName}自定义解析后的key名称

_bean{(a,b.c)->funcName}多参数跃接。_bean开头为绝对路径寻参，this开头为相对路径寻参，super开头时后退一级。默认this开头，允许${}插入自定义资源

（用法须知：路径寻参原则上仅在跃接语句中传参使用。但可以扩展支持）

_bean{"name":"const"}如果value部分用双引号引起来，则认为是常量，直接插入结果中

_bean(name1||!name2){}注解检查，语法参考条件语句。如果属性或get方法上存在指定的注解，则依据检查依据决定是否解析

_bean!{a,b}除了a,b 剩下的都解析