数据权限的设计与实现系列12——前端筛选器组件Everright-filter集成功能完善3
筛选条件数据类型完善
数值类
筛选器组件给了一个数值类类操作的范例，如下：
Number: [
{
label: '等于',
en_label: 'Equal',
value: 'equal',
style: 'noop'
},
{
label: '不等于',
en_label: 'Not equal',
value: 'not_equal',
style: 'noop'
},
{
label: '大于',
en_label: 'Greater than',
value: 'greater_than',
style: 'noop'
},
{
label: '大于等于',
en_label: 'Greater than or equal to',
value: 'greater_than_equal',
style: 'noop'
},
{
label: '小于',
en_label: 'Less than',
value: 'less_than',
style: 'noop'
},
{
label: '小于等于',
en_label: 'Less than or equal to',
value: 'less_than_equal',
style: 'noop'
},
{
label: '区间',
en_label: 'Between',
value: 'between',
style: 'range'
},
{
label: '为空',
en_label: 'Empty',
value: 'empty',
style: 'none'
},
{
label: '不为空',
en_label: 'Not empty',
value: 'not_empty',
style: 'none'
}
]
}
平台进行以下调整：
- 区间可以可以等价转换一个条件组，内含两个条件，大于等于最小值，小于等于最大值，组内逻辑关系为且。而且可以只设置其中一部分，更灵活，因此去除区间。
- 对操作符的编码做相应调整。
调整完成后如下：
Number: [
{
label: '等于',
value: 'EQ',
style: 'noop'
},
{
label: '大于',
value: 'GT',
style: 'noop'
},
{
label: '大于等于',
value: 'GE',
style: 'noop'
},
{
label: '小于',
value: 'LT',
style: 'noop'
},
{
label: '小于等于',
value: 'LE',
style: 'noop'
},
{
label: '不等于',
value: 'NE',
style: 'noop'
},
{
label: '为空',
value: 'NL',
style: 'none'
},
{
label: '不为空',
value: 'NN',
style: 'none'
}
]
获取规则条件时，需要将数值类的操作符指定为Number，做以下调整：
/**
* 获取完整属性列表，转换为过滤器需要的格式
* 只取数据库存储的属性
*
* @param entityModelId 实体模型id
* @return {@link ResponseEntity}<{@link Result}>
*/
@GetMapping("/{entityModelId}/getFullPropertyListForFilter")
@SystemLog(value = "实体模型属性-完整列表，转换为过滤器格式")
@PreAuthorize("hasPermission(null,'entityconfig:entityModelProperty:query')")
public ResponseEntity<Result> getFullPropertyListForFilter(@PathVariable String entityModelId) {
// 构造查询条件
List<EntityModelProperty> list = entityModelPropertyService.getFullPropertyByEntityModelId(entityModelId);
// 转换vo
List<EntityModelPropertyForFilterVO> entityModelPropertyVOList = new ArrayList<>();
for (int i = 0; i < list.size(); i++) {
// 获取属性定义
EntityModelProperty entityModelProperty = list.get(i);
// 非库表存储属性直接跳过
if (entityModelProperty.getDatabaseStoreFlag().equals(YesOrNoEnum.NO.name())) {
continue;
}
// 获取平台展现属性的控件类型
String dataType = entityModelProperty.getDataType();
String widgetType = entityModelProperty.getWidgetType();
String[] numberDataType = {"INTEGER", "LONG", "DOUBLE", "DECIMAL"};
String renderType = "TEXT";
String operatorKey = "Text";
switch (widgetType) {
case "TEXT":
if (ArrayUtils.contains(numberDataType, dataType)) {
renderType = "NUMBER";
operatorKey = "Number";
} else {
renderType = "TEXT";
operatorKey = "Text";
}
break;
case "TEXTAREA":
case "RICH_TEXT":
renderType = "TEXT";
break;
case "DATETIME":
renderType = "DATETIME";
break;
case "TIME":
renderType = "TIME";
break;
case "DROP_DOWN_LIST":
case "RADIO_BUTTON_GROUP":
renderType = "SELECT";
break;
default:
renderType = "";
}
if (StringUtils.isNotBlank(renderType)) {
EntityModelPropertyForFilterVO vo = new EntityModelPropertyForFilterVO();
vo.setLabel(entityModelProperty.getName());
vo.setValue(entityModelProperty.getCode());
vo.setRenderType(renderType);
vo.setOperatorKey(operatorKey);
entityModelPropertyVOList.add(vo);
}
}
return ResultUtil.success(entityModelPropertyVOList);
}
后端将规则转换成SQL片段的功能方法在文本类已经相应处理过了，测试如下：
符合预期。
日期时间类
日期时间类原来计划是需要处理的，做的过程中意识到，实际业务需求不会存在按照日期和时间来配置数据权限规则的。
因此在返回筛选条件时，将日期时间类的属性也去除掉。
数据字典
接下来重点攻坚数据字典。
从数据权限规则配置角度，同样我们不使用多选，有需要时转换成多个条件就好了。
官方文档中这块说得很少，除了上面常规属性外，增加了两个属性，multiple是否可以多选，multipleLimit，限制多选的最大数量，如下图：
但是下拉的数据源哪来的，如何赋值呢？
仔细观察上面例子，原先的操作符里放了Gender，看上去像是数据字典类型的编码。
然后在API Conditions部分，就放了一个select的示例，啥也没说……
只能动手摸索了。
还是拿先前的功能验证页面进行快速验证，做如下调整：
为筛选器组件绑定方法，如下：
然后在原有筛选条件的基础上，增加一个性别的条件，并在操作属性中同步新增一个Gender对象，如下：
最后，就是下拉列表的数据的如何构建了，尝试如下：
const getConditions = async (params) => {
return new Promise((resolve, reject) => {
resolve({
data: {
conditions: {
gender: [
{
label: '男',
en_label: 'male',
value: 'male'
},
{
label: '女',
en_label: 'female',
value: 'female'
}
]
}
}
})
})
}
运行后无法加载下拉数据，效果如下：
控制台报错：
尝试将conditions中的gender更改为大写Gender，错误依旧……
关键在于，下拉列表的数据源，是如何跟筛选条件关联到一起的，在option对象不增加属性的情况下，要不然是复用了操作operatorKey，要不然是复用值value，后者的可能性更大，实际测试，两条路都不通，这就难办了……
再翻了一遍官方文档和demo，没有找到例子，百度和ai搜索也没有结果，还得继续摸索。
然后看到getConditions 方法是带参数的， async (params)，这里面的params推测是数据字典类型的编码gender（对应着筛选条件的value值），用console.log验证了下，果然是这样，然后改写了下处理：
const getConditions = async (params) => {
const { property } = params
console.log(property)
if (property === 'gender') {
// 当 property 为 'gender' 时，返回相应的条件选项
return new Promise((resolve, reject) => {
resolve({
data: {
conditions: [
{ label: '男', value: 'male' },
{ label: '女', value: 'female' }
]
}
})
})
}
}
结果还是不行。
精简数据层次结构，去除了conditions节点，直接让data包裹数据，如下：
const getConditions = async (params) => {
const { property } = params
if (property === 'gender') {
console.log(property)
// 当 property 为 'gender' 时，返回相应的条件选项
return new Promise((resolve, reject) => {
resolve({
data: [
{ label: '男', value: 'male' },
{ label: '女', value: 'female' }
]
})
})
}
}
下拉数据源终于实现了，如下：
demo验证通过了，开始做正式功能。
这里有个问题需要解决，筛选器组件复用了条件对象的value属性，即要求数据字典类型的编码必须跟条件的编码完全一致，这样会存在限制，因为实际条件的属性编码跟数据字典类型编码通常是不一样的。
该参数是内部传递的，无法扩展，因此只能采用变通的方式，我们在获取到实体属性定义的时候，将属性编码和数据字典类型对应关系先缓存下来，然后依据缓存的对应关系找到数据字典类型编码，然后再调用后端服务获取字典项加载。
首先，前后端交互的视图对象类型中，新增数据字典类型属性，如下：
后端查询实体模型属性的时候，如果该属性为数据字典，则写入字典类型编码，同时操作定义统一为DataDictionary，如下：
前端在调用实体属性列表时缓存对应关系，如下：
前端添加筛选条件为数据字典时，触发数据字典项查询服务，如下：
async getConditions(params) {
// 根据缓存的对应关系，获取到属性对应的数据字典类型编码
const dictionaryType = this.propertyDictionaryTypeMapping[params.property]
return new Promise((resolve, reject) => {
this.$api.system.dictionaryType.getItem(dictionaryType).then((res) => {
if (res.data.length > 0) {
res.data = res.data.map((item) => {
// 后端范围的value是id,code才是编码，因此需要转换
return { label: item.label, value: item.code }
})
}
resolve(res)
})
})
}
还有就是给数据字典类型新增一个固定的操作集合，只有等于或不等于即可，如下：
最后，运行效果如下：
点击生成规则以及转换SQL片段，符合预期，如下：
开源平台资料
平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：[csdn专栏]
开源地址：[Gitee]
开源协议：MIT
如果您在阅读本文时获得了帮助或受到了启发，希望您能够喜欢并收藏这篇文章，为它点赞~
请在评论区与我分享您的想法和心得，一起交流学习，不断进步，遇见更加优秀的自己！