2017-12-15 16:58
@Shydow 对比一下 jfinal 3.3 的 I18nInterceptor 源代码就知道了,这个代码确实有问题,次序不对,自己建个拦截器,继承一下 I18nInterceptor 拦截器,覆盖一下 intercept 方法,照着 jfinal 3.3 的代码调整一下即可
jf 3.3 的源码在首页的 jfinal-3.3-all.zip 中可以下载到
2017-12-13 22:18
@badouyuren 只要不是复杂 order by 就没事,用正则去除复杂 order by 性能会下降一个数量级,权衡后引入 paginateByFullSql
大部分 sql 的 order by 都能搞定,一般没事
2017-12-13 16:48
1:一开始是为了使用同样的 url 值,通过 GET、POST、PUT、DELETE 去请求不同的 action 方法,例如:
GET localhost/user/1 用于访问 UserController.detail() 方法
PUT localhost/user/1 用于访问 UserController.update() 方法
除了上面的 GET、PUT 这些以外,还有一些 DELETE、HEAD 之类的 对应到更多的 action 方法,但是 http 协议里头并不支持 DELETE 等请求类型,所以请求类型不够用,要完全实现,就需要引入隐藏表单域并用 POST 请求来辅助
上面的用法很鸡肋,所以 spring 在实战中并没有利用这个机制来制定 URL 规则。绝大部分情况仍然是用不同的 url 访问不同的 action,但 spring 已经忘记了来时的路,还在继续用着 GetMapping、PostMapping 这样原先为了别的目的而建立的规则
jfinal 则不同,是直接就跳过那些鸡肋设计,将请求类型动作直接放在 url 中,例如:
localhost/user/delete/1
localhost/user/update/1
此外,还有一个谈不上好处的功能,就是你的 GetMapping 注解过的 action 无法被 POST 请求访问到,仅是一个功能,实际用处从没人提出来过,估计是没有任何好处
2:用 Post 做所有请求,那么网页中的超链接就没法访问到这些 action 方法了,因为浏览器的在点击超链接时发起的是 GET 请求
3:jfinal 通过深入分析 rest 建议的 url 风格,以及 spring 的实践,认定是个鸡肋后,做出的最终设计,简洁、方便、性能高、学习成本低
2017-12-13 16:32
@阿普 已提交 issue: https://gitee.com/dreamlu/Easy4JFinal/issues/IGSOH
感谢你的反馈
2017-12-13 16:27
@leomj 没有主键的话, model.save()、model.update()、model.delete() 这些方法就不可能实现,前面这三个方法生成 sql 时,都是要依赖 id 生成 where 部分的,例如:
...... where id = ?