2022-06-29 18:18

为啥不用 model.keep(...) 与 model.remove(...)

2022-06-22 23:03

非常实用,点赞 + 收藏

第二步的 pom.xml中build里编辑 好像可以省

2022-06-20 22:25

看上去是缺少依赖,在 pom.xml 中添加 jfinal-undertow 依赖

2022-06-20 22:25

不同线程明确知道需要共享 ThreadLocal 中的对象时,下不需要 remove(),例如 JDK 中的 java.math.BigDecimal 中的 threadLocalStringBuilderHelper

共享变量类的缓冲区也可以不必 remove,例如 enjoy 中的 WriterBuffer,多个线程在不同的时间段内可以共享,而 ThreadLocal 可以保障同一个变量在每个时刻只被一个线程使用

2022-06-17 19:03

@konguwmang jfinal enjoy 是在后端起作用,后端生成完 html 内容以后才交给 laytpl 去使用

所以,你只要想办法用 enjoy 生成 laytpl 能用的格式就行,一定要将后端与前端区分开来,有一个先后次序问题,工作次序不要搞反,也不要搞混

2022-06-17 18:38

@konguwmang enjoy 不支持这种表达式: #set(Qualifylist = {{data}})。

在指令小扩号内的属于 enjoy 表达式,需要遵守表达式语法,而 {{data}} 语法错误

你是不是想这么来用:
#set(Qualifylist = "{{" + data + "}}" )

2022-06-17 18:37

提示信息你的 enjoy 表达式有错误, 检查表达式中的冒号字符 ':' ,这个字符前后组合而成的表达式不符合格式

例如: #( x : ) 这表表达式 x 后面多一个冒号无法匹配

再例如: #( x ? y ) 这表表达式 y 后面缺少一个冒号无法匹配

2022-06-15 12:16

大概率是 EpRequestWrapper 中没有接管到某些 getter 方法,而参数注入调用了 getParameterMap 等方法去注入

参考 jfinal 的 JsonRequest:
https://gitee.com/jfinal/jfinal/blob/master/src/main/java/com/jfinal/core/paragetter/JsonRequest.java

这里头接管了 getParameterMap()、getParameter(...)、getParameterValues()、getParameterNames()

JsonRequest.java 中从 getInputStream() 开始往下的一些方法仅为转调,不必关心

2022-06-14 18:24

输出是在哪里输出的?

如果是浏览器中或者 js 输出的,那么这个值 1536612013134974976l 超出了范围

在浏览器中,按一下 F12,打开开发者工具,然后点击 console,在命名行输入:
var x = 1536612013134974976;
console.log(x);

输出值为:
1536612013134975000
该值已得到确认,与你的输出一样

这个并不是 renderJson 转换出错, google 搜索一下 javascript long , 找找解决方案,一般是将这类可能超出范围的 long 型按 String 处理

2022-06-05 15:54

新版本可以配置针对 json 请求的响应值:
me.setErrorJsonContent(...)

具体用法如下:
me.setErrorJsonContent(404, Ret.fail("404 Not Found").toJson());
me.setErrorJsonContent(500, Ret.fail("500 Internal Server Error").toJson());

2022-05-30 19:36

@jfinal爱好者22 jfinal 中大部分代码是 10 年前的,最简洁的设计在 com.jfinal.template 下面,即便是这下面,也是 2016 年的代码了

2022-05-29 19:20

已 fork、start、点赞、收藏,功能全应该很有用

2022-05-29 11:21

独立版本的 activerecord 不依赖 log 模块,要去掉所有 Log.xxx 有关的代码这是出发点

去掉以后,为了不丢失异常,多数地方应该要抛出异常给上层,上层再做日志就能保全异常信息,通常上层用一个全局拦截器即可收集所有这类异常

为啥没有继续向上层抛出,是因为 finally 上方还有一个 catch (Exception e) ,那么当 catch 与 finally 同时出现异常,catch 中的异常将丢失,但 catch 中的异常远比 finally 中的重要

因为 catch 中多数是与 sql、参数甚至业务有关的异常,而 finally 中可能就是一个数据库连接断开的异常

最后 finally 的 conn.setAutocommit(..) 出现异常的概率极低,综上考虑 ......

2022-05-18 13:12

@飞水 上面的用法是对,注意 index 的值要是 int/Integer 类型,高版本 enjoy 支持 long/Long 类型

2022-05-17 23:14

@21th 5.0.0 版本新添加的可选链操作也挺香的,记得用上:
article?.account?.getNickName()?.length()