2019-07-10 11:34

@牛打下 默认转 json 的实现,会严格按字段名来转,如果你原来的字段是驼峰的就没问题

如果你的这个转换是很少出现,可以用下面的方法来做:
String json = FastJson.getJson().toJson(...);
renderJson(json);

也就是说多数情况使用默认的, 少数特殊情况使用指定的方式来转

默认的 JFinalJson 有一个好处:转换不依赖于 getter 方法,那么关联查询得到的字段值,以及 put 方法放入的字段值也会被转换

而 fastjson 的转换严格依赖于 getter 方法,所以无 getter 方法的值是无法转换的

各有利弊,选好默认,然后用好个别情况

我个人的使用习惯是:
1:mysql 中的字段名使用驼峰形式
2:model 生成 getter、setter 方法
3:配置: me.setJsonFactory(new MixedJsonFactory());

这个使用习惯,一是可以保障 JFinalJson、FastJson 在转 json 时的结果是一致的,因为无论是字段名与 getter 方法转出来的都是驼峰了

不仅转出来值是一致的,而且 MixedJson 支持转换 Model.put 进来的值,以及支持关联查询得到的关联表中的值,而这些值是没有 getter 方法的

2019-07-10 11:32

你可以认为两个地方重用同一个逻辑,引入了一个适配性的参数

2019-07-10 11:31

Dialect.forModelSave(...) 方法是用来为 Model.save() 生成 sql + para 的

而 batchSave 方法可以重用这个方法,但是并不需要生成 para,所以这个参数是为了重用 来生成 sql,但不能缺少参数而提供的

2019-07-10 11:29

@tekeyoko actionKey 重复会明确报一个 action already exists 的异常, NoClassDefFoundError 这个一般是缺包引起的

2019-07-10 10:37

json 转换默认用的 JFinalJson, 只会处理 Model 的 Map attrs 值

如果希望通过 getter 转换,配置一下:
me.setJsonFactory(new FastJsonFactory());

文档中有过说明:
https://www.jfinal.com/doc/12-3

2019-07-09 22:47

结合微信小程序的官方文档看一下就知道了

2019-07-09 21:28

一般情况建议使用 jfinal demo 中的 layout 函数来布局,当前你的布局方式在 _meta.html 中的 html 标签是不成对的,一部分在 _meta.html 中,一部分在你当前的页面中

2019-07-09 21:25

后端代码看上去没有问题,打开浏览器的开发者工具窗口, 看一下返回值,如果有错误的话也可以在浏览器开发者工具中看到

2019-07-09 21:22

其它的 web 框架在启动时打印的内容比 jfinal 多得多

这些启动信息对于了解项目的启动状态是有帮助的

如果启动的时候不输出任何信息,这才是最该引起担忧的,你不知道启动成功没成功

2019-07-09 21:20

通过 JDK 代理 druidPlugin 这个思路第一次见,挺有新意,谢谢分享

2019-07-08 22:49

信息量不够,一没代码,二没异常,三没 sql

2019-07-08 22:47

整个异常中都没出现 jfinal 字眼,肯定是与 jfinal 无关的

将关注点转移到异常的 cause 部分:
Caused by: java.lang.IllegalArgumentException: javax.faces.context.ExceptionHandlerFactory

2019-07-08 22:46

本来是不回复这个问题的,但忍不住要说一句

你的提问信息量严重不足, 一没给出详细的异常,二没给出代码,三没给出 sql

如果换成是你自己来回答这个贴子,你觉得是否有回答的空间?

2019-07-08 22:45

使用 OpenOffice 将 doc 转为 pdf 这个是头一回见,很好的分享,希望对后来的同学们有帮助

2019-07-08 22:43

@Miii 这样大段的 sql 应该使用 sql 模板进行管理:
https://www.jfinal.com/doc/5-13

有关分页的问题,一定要看文档,里面针对各种问题做了解答:
https://www.jfinal.com/doc/5-6

如果是查询、分页慢的问题,用 mysql 的 explain 命令检查查询是否是在 "索引" 上进行的,否则如果数据量大肯定慢,只要是大数据量的全表扫描必然慢

注意:查询慢的问题必然与 jfinal 无关,因为 jfinal 只是将你的 sql 与 para 直接扔给了底层的 JDBC,并不会对你的 sql 有过多干预

JDBC 层面都慢了,那么只能优化 sql 或者索引