2022-07-11 22:35
如果开发团队有专职的前端工程师，前后分离能提升开发效率
现阶段前后分离算是比较好的开发模式，随着技术的发展，前后会再次回归整合，只不过那时候的整合以吸收了本轮前后分离技术优势之后的模式
对于 jfinal 来说，将原来的 render(xxx.html) 改成 renderJson(...) 就可以了，我这从去年 11 月份一直用到现在，非常顺滑
2022-07-01 18:40
如果你用的是 jfinal 的 DruidPlugin，可以针对 Druid 做一个 Filter 出来，在它里面对所有数据操作记录一下最后的时间，覆盖掉 Filter 中的一些方法做记录，如：
preparedStatement_executeUpdate
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());
