对于数组的异常打印,如果需要,可以展示下标

最新在学习Rust,看下是否Rust中也需要核查框架,那么建议这里也开发mikilin-rust客户端

rust不需要,因为rust版本的validator功能跟我们现在的这个比较像,或者说已经具备了大部分功能

支持国际化

目前其中中文较多,建议支持国际化,也就是英文的支持

支持kotlin语言

发现Kotlin和java在反射方面的用法还是有比较大的区别,因此这里建议创建基于kotlin的专门的jdk包

最近在学习go,发现go中的也是采用validate框架,也是有很多功能局限性,我们的理念也可以运用在go语言中,因此开发了go版本的项目

https://github.com/SimonAlong/mikilin-go

核查异常的map其中在customize情况下,其中异常map不能搜集

拦截后抛异常,这个异常可以自定义

高性能核查方式——这个建议改变为将aop方式进行替换掉,aop方式确实性能有问题,但是可以换成读取其中的变量,添加到过滤器中看下是否可以

目前我这边的所有处理全部都是通过反射的方式获取数据,并进行核查,昨天跟阿里的面试中了解到反射这个在一些极端情况下会存在性能问题,因此这里进行改造,用法方面不变化,但是内核的检查方面做一个变化处理

核查异常的顺序——需求不多,暂时不考虑

目前对于对于结构的核查,采用的是有任何一个属性核查失败,则就会直接失败,不再核查其他的属性,为的就是节约cpu资源,但是对于个别的有些时候希望核查更多的,则可以提供一个属性,让业务方自己决定。目前这个决定的位置,我这里建议放到@AutoCheck这里,因为对于@Matcher这个注解,里面的各种匹配器,现在是都会核查一遍的,放到@AutoCheck才是最合适的位置

身份证号校验加强

目前现在的身份证号只是对一些位数的校验,但是有些不存在的一些身份证号,在一些更加严格的身份证号的校验规则情况下是通不过的,但是在已有的这个规则中是可以通过,因此建议将这个规则严格度增加。借鉴这里
https://www.yuque.com/simonalong/jishu/qqxkzl

系统自定义回调的路径支持鼠标点击跳转

现在路径是直接写死的,而且不支持鼠标点击后的跳转,添加一个功能,能够支持鼠标点击路径后跳转

异常信息展示

这边有需求需要对异常进行成对的展示,需要将待核查对象的具体核查错误的用map的形式展示出来

@Matcher新增属性matchChangeTo

新增属性满足某个条件后,将属性的值设置为另外一个,目前准备在注解@Matcher中新增一个属性叫matchChangeTo,中文翻译过来叫“匹配后则转换为”

MkContext 添加功能

目前遇到一个问题,就是如果多层嵌套的参数,进行核查的时候,如果想使用上一层的参数,则无法获取,能做的就是只能在业务代码

时间范围

[now-7d,]:表示当前往前推7天,最近7天
支持

  • y:年
  • M:月
  • d:天
  • H(h):小时
  • m:分钟
  • s:秒

例如:
7d3s78ms:表示7天3秒78毫秒

这样就会更灵活了

如果为空,则将该值进行设置下

mikilin中的一个字段如果为空,则将该字段进行设置

支持对参数的核查

image.png
image.png
其中这种参数为基本类型的考虑下进行核查,这样所有的核查都可以进行实现了

默认的异常信息中将字段的名字展示出来,要不然不知道是哪个

默认的异常字段中,核查字段过多,简化下

错误异常添加#root字段

customize多参数时候匹配失败,重载的配置有问题

多个@Matcher注解修饰的时候,一旦其中一个出错然后上报的异常日志显示的对应不上

customize多参数的匹配自动化

目前这个字段的多参数匹配采用的是固定的几种类型,而不是根据参数自动的进行匹配,可以考虑将这个进行自动化的配置起来,建议在新的版本中处理好

AutoCheck能够修饰参数——这个修改为@Matcher修饰参数

目前由于之前遇到的final导致启动失败问题,进而无法修饰参数,这个我觉得后面可以考虑修复下,看下怎么进行支持下

注解中的true和false可以配置为非包装类

AutoCheck其中的group属性采用数组方式

目前是核查一个,建议采用核查多个的形式

添加@AutoCheck,修饰spring-web中的@Controller中对应的Bean

目前@Check和@Matcher如果同时修饰集合类型,则集合类型的range(大小匹配)不生效

目前属性如果为null,则响应的一些核查可能会有点问题,后面进行修复下

一个对象为空,则看下这个对象是否为基本类型,如果为基本类型,则不关心

文档补充

对于复杂场景的补充
比如:

  1. @Data
  2. public class HandleColumnInsertReq {
  3. private Long appId;
  4. private Long tableId;
  5. private Long columnId;
  6. /**
  7. * 处理类型:0,新增;1,编辑;2,搜索;3,表展示;4,表扩展
  8. */
  9. @Matcher(range = "[0, 4]", errMsg = "不识别类型 #current")
  10. private Integer handleType;
  11. /**
  12. * 是否可编辑(只有为编辑类型时候可用):可否编辑:0,不可以;1,可以
  13. */
  14. @Matcher(condition = "#root.handleType == 1 && #current != null")
  15. private Integer editFlag;
  16. }

场景:
其中字段editFlag,该字段的值只有handleType为1的时候,必须为0和1中的一个,为其他值的时候,这个值为空或者不关心都可以了

枚举能够支持name的解析这个确认下

将AutoCheck添加到Mikilin中

这个可能需要spring的扫描,那么扫描下就扫描下吧

顺便对这个AutoCheck新增,group功能

Matcher中的range可以支持修饰的类型:

1.修饰String:则表示string的size长度
2.修饰Number(已支持):表示数据的大小
3.修饰Collection(已支持):表示集合的大小

Matcher中的model添加类型:

添加中文匹配

增加对JSR-303协议的支持——JSR-303的一些功能感觉真的没有必要

我觉得可以增加对这个的支持

编写文档,输出Hibernate.validate和我们框架的区别

异常匹配器的集成测试

用于针对异常类型的继承测试

@Matcher(value = “”, access = false)

这个就是如果为null或者””空字符这种,就会拒绝,但是目前不能生效

groovy修复复杂表达式问题

目前对于复杂一点的表达式还是有点问题,尤其是在那种

多个匹配器进行与操作

目前多个匹配是或的操作,只要任何一个类型的匹配器匹配上,则就可以进行下一步,但是如果要求多个匹配器同时满足呢,这个就不行了。目前考虑支持将多个@Mather放到一个属性上面,比如
@Mather(value={“a”, “b”}, access=false)
@Mather(condition=””, access=false)

errMsg里面可以将变量放进

方便输入使用

黑白名单进行合并(finish v1.5.0)

我觉得有没有必要将黑白名单进行合并,这样将黑白名单这么个作为一个独立的属性位于其中,其中默认为白名单匹配器,如果采用黑名单,则就是匹配之后进行拒绝呢,我觉得可以,这个下午进行开发,开发完成后,将这个再同步到自己的那个需求中。

添加一个属性,用于在核查失败之后用于展示自己的核查失败文案

添加后,这样可以更加个性化的展示

添加自动核查注解@AutoCheck

这个参数可以修饰函数,也可以修饰参数,其中在函数执行的时候进行核查所有的参数,如果修饰参数,则参数对应的函数
答:
这个已经在一些业务里面做了,但是这个建议还是做到业务里面,因为这个不属于框架层面

动态生成正则表达式

是否有这种引擎,通过输入数据,将这些数据

考虑动态添加匹配规则

目前所有的配置规则都是静态的在开始就配置好的,是否可以考虑将匹配进行动态化,给外部开放接口,让外部实现添加新的过滤匹配规则。
这个采用bloom 过滤器的方式进行处理

Checks这个名字是否可以改一下(finish on v1.4.5)

我发现很多框架中都是用Validators这么个名字,那好的,我们后面将Checks这个类弃用,后续版本采用MkValidators

接入spring部分

在spring的代码中,添加核查注解,目前考虑新增spring的项目

功能:
1.添加一个注解@AutoCheck
1.用于启动核查,该注解可以修饰函数,则函数的所有入参和出参都会进行核查,该注解也可以修饰类,则会核查类中的所有函数的入参和出参
2.注解中包含一个属性,为group,表示核查指定的属性
2.添加一个激活Controller的AOP注解

核查失败的错误输出优化(v1.4.3 finish)

目前失败的错误输出还是靠着链式的错误结果输出的,这个对日志格式还是有好的,但是对于前后端排查来说不是很方便,而且也不是很友好,因此,这里建议添加这样的功能,能够直接在界面上进行展示出来

range属性的优化(v1.4.4)

目前比较这里如果要匹配大于符号,则采用的都是(a,null),这个可以优化为(a,)这种,以及小于(,a)这种。

属性的异常核查机制(v1.4.4)

针对属性中如果不是合法的值,则进行拦截校验,这里增加统一的异常校验机制

属性的排查

1.Range属性中,关于时间的介绍,这里如果输入的past和future不合法,则要编译报异常
2.condition中属性的自增,会不会对本身的值发生变化

主页介绍,添加快速入门(v1.4.3 finish)

由于主页这里并没有快速入门,因此很多人看到之后,转到文档的可能性比较小,因此还是建议做一个快速的入门

核查所有的类型

针对List<?> 、List 和List 这三种泛型进行拆解,看下怎么进行拆解开

集合类型的size判断

数据的size的大小,有些时候需要设置,这个看下要怎么设置下
目前该功能接入到range属性中

属性为null的判断,有些是有对属性要求不为null

其实目前所有添加上注解的属性都默认是不能为null的,但是也不排除有些就是有对这个null的要求

系统自定义回调失败中信息添加

目前系统自定义回调中,如果最后核查失败,对应的失败msg,是系统中的,看下是否需要再系统自定义回调中添加新的回调的填充

系统自定义回调减少一个类中的多个判决函数

对于有多个参数都是同一个判断类中的,可以将路径放到类上面,属性中使用“#函数名”

系统自定义回调的路径支持鼠标点击跳转

现在路径是直接写死的,而且不支持鼠标点击后的跳转,添加一个功能,能够支持鼠标点击路径后跳转

实现JSR-303

目前所有的需求还是根据自己的想法,现在想更规范化,因此这里准备实现一个JSR-303协议的功能
借鉴其中的属性的类型

一次性核查所有的不合法数据

当前的逻辑处理是一旦匹配到不合规范的,则直接返回,不再向后继续执行,这样性能会比较好,但是无法一次性的将所有不匹配的错误给展示出来,也是问题

range添加时间范围

如果是时间类型,则这里按照进行时间的展示进行范围过滤,而且建议增加几个函数,比如now,还有future,还有past

系统回调的单例实现接入spring的bean

目前系统回调的部分,采用的是自己进行独立实现单例化的模式,但是在spring中,我们这里独立的单例化设置算是打破了spring的bean单独配置,因此建议接入spring的单例化配置。看下怎么接入

时间固定类型

有些字符串或者展示格式要求为某些固定的格式,这个可以设置显示下

分组的扩展

目前的分组功能是每个匹配器里面分组是只能放一个,但是如果现在有很多的分组,然后有好几个分组的逻辑是一样的,那么这个时候这个组的可以放多个的场景还是存在的

防止死循环问题

对于类型的引用,如果里面已经有对应的结构,则不需要再向里进行解析,否则会造成死循环

分组

不同场景进行设置不同的校验规则,目前情况下是一个bean中的规则是对所有的场景都是生效的

系统回调校验升级

系统回调校验内部可以将表达式的对象带上

建议注解命名方式变化一下

目前黑白名单机制这里,其他所有的属性按理说应该是匹配,应该叫匹配,而不应该叫核查,相关的文案我觉得应该也要改下

核查指定的属性

核查函数目前只有一个,现在准备引入新一个新的函数,可以指定核查对象的某几个属性