Robot.L

+1

An input tag with required（whatever ' required="true" ' or ' required="false" ' ）.it will be required to have a value.This is the case in HTML.

> 主要步骤： > > 1、基于源码进行构建,`knife4j-vue`，参考文档：https://doc.xiaominfo.com/docs/community/contributing > > 2、修改文件[BasicLayout.vue](https://github.com/xiaoymin/knife4j/blob/dev/knife4j-vue/src/layouts/BasicLayout.vue),针对`created()`方法中，修改使用`this.initKnife4jFront()`方法 > > 3、修改`this.initKnife4jFront()`方法中的url属性，改成你们自定义的接口地址 > > 4、url接口响应回来的结构需要满足如下格式,格式参考[blog](https://doc.xiaominfo.com/docs/faq/knife4j-exception)： > > ```json > [ > { > "name": "2.X版本", > "url": "/v2/api-docs?group=2.X版本", > "swaggerVersion": "2.0",...

收到，后续跟进

只要两者依赖的mybatis版本一致，理论上是互不影响的

> > Mybatis-Flex会自动忽略null，这是设计如此，官网已经讲述比较清楚了，并非BUG。见QueryColumnBehavior章节。 > > 我知道默认会忽略，可是这个方法后面是有条件进行控制的。有条件的情况下，不应该忽略呀 既然知道参数为null或空集合执行sql会报错，为啥还要这样设计，不应该自己判断in参数为空的执行逻辑吗，无非就是两种：忽略条件或者返回空结果集，flex默认是忽略条件，如果你的业务场景是后者，就在执行sql前做一次判断空集合，是的话就直接返回。flex这么设计没毛病的

留Mapper这一层还是有一些用处的吧，比如配合mybatis原生注解写一些简单的sql，如update..set version = version +1。或者使用default方法组合多个BaseMapper的方法（没业务逻辑纯操作sql，放在Mapper层比service层更合适）等等 如果项目小，快速使用的话可以用ActiveRecord应该更方便，项目大就保留Mapper这一层。

很棒的实现思路👍👍👍，不用考虑解包器、嵌套转换、方法申明注解，确实方便了非常多，几个问题可以探讨一下： 1. dubbo这种一般不用json序列化场景，好像没办法处理了，AOP的方式是spring任何springbean的方法上都能用，那么这块可能在权衡之后可能要放弃支持？ 2. 注解由目标字段转换到源字段，是否有必要——标注在目标字段更好维护一些，能一眼看出哪些字段是转换而来的。另外在同一个源字段转换成多个目标字段时的这种场景，支持得也很丝滑，你的方式对于这种场景还要多一些处理。个人还是偏向原来的使用方式。 3. 枚举的转换实现改了，可能需要支持原来的功能——Integer的情况还是蛮常见的，需要支持，可以考虑同时兼容枚举和Integer。ps.不过话说回来，Dict已经有`getAll()`方法能提供枚举所有code和text对应关系，客户端先接口拿一下这份数据（一般查询条件下拉框也需要），客户端自己做下渲染也是可以的 4. 既然已经是json序列化的方式实现，这块有没有可能解析之后直接将转换结果写入目标json中，而不用反射塞值了，这样性能应该也能快不少，这里使用反射的方式有个缺陷，就是目标值在vo类中的位置必须在源值的后面（sexName必须定义在sex之后），不然转换失效

项目模块调整的时候忘记注入这个bean了，近期修复。 如果着急使用的话，可以先手动声明一下`ForeignKeyTransformer`这个bean，在Configuration类或者Application类上使用如下代码： ```java @Import(ForeignKeyTransformer.class) public class Application{ ... ```