2017-03-20 19:25
@hmgx jfinal 3.0 已经直接支持该功能，参考一下 jfinal 手册有关 cron4j plugin 这一章节
2017-03-20 19:01
DbPro 的构造是自动的，所以 DbPro.init 这个方法对用户来说是不可见的，正确的构造方法是创建一个 ActiveRecordPlugin 对象，然后启动它，DbPro 自然就被创建好了，后续直接使用即可
如果希望自己动态添加 Config 从而创建 DbPro 对象，正确的流程是将 Config 传给 DbKit.addConfig(config) 方法，然后 DbPro 的创建也是自动的
简单来说 DbPro 对象的管理是动自动化的，所以也就不存在初始化和构造 DbPro 这类问题了
2017-03-20 18:51
@abvcb 如果是非浏览器客户端，而是专用的 http 客户端，确实可以直接在 http 协议中体现 PUT、DELETE 这类请求类型，但这样做其实没什么必要，而在 url 中放入请求类型在语义上表达更为明确，站在 API 的使用者的角度看，更容易理解，可读性也更强
从开发实践的角度来说，在代码中必须去指定某 action 为某请求类型，这也会增加代码量，拉低开发体验。抽象资源用什么请求类型映射至某个 action，要么用约定的方式，要么用注解或配置的方式指令，这都会增加学习成本，但却看不到一点好处
2017-03-19 18:37
分享贴和代码全有了，非常用心，对 restful 的改进很简单直接，非常感谢你的分享
现在 jfinal 用户基数非常大，所以对于这类改变要非常小心谨慎，如果确实要改进，也需要确保原有的使用方式可以被兼容，楼主的分享中也谈过了一些不足，所以是无法收了这功能的 ^_^
其实，jfinal 一直没有彻底的去支持 Roy Fielding 博士在他论文中提出的 RESTFUL 风格的 URL 是有强烈的原因的
首先，RESTFUL 是一种软件架构风格，该架构风格的内容很丰富，其核心在于资源的抽象，并不在于 URL 的风格，URL 风格仅仅只是 RESTFUL 对 URL 提出的一个建议，并非行业标准，更非事实标准。很多人将 restful 风格的 URL 当成了 restful 架构本身，这是个误解
其次， Roy Fielding 博士在论文中建议的 restful url 风格并不接地气。有些浏览器并不支持 DELETE、PUT 之类的请求类型，而是通过提供类似于 _method 这样额外的参进行模拟。不接地气还体现在：对资源的操作类型很可能会超出 POST、GET、PUT、DELETE 等等类型
最后，jfinal 自身在更重要的资源的抽象上建议 RESTFUL 风格，但对 url 风格保持了自己的优势，那就是将对资源的的操作从 http 的协议中转移到 url 之中，仅此而已，例如 DELETE 这个动作，在 jfinal 中是 abc.com/resource/delete/id
restful 本身是一个软件架构风格，而 url 仅为其中的一个建议，并且这个建议并不是那么接地气，所以现在腾迅、阿里、百度这些巨头的开放平台提供的 url 都是 jfinal 的风格，这里举出一下微信公众平台的 API 的 url 风格：
1：创建菜单：https://api.weixin.qq.com/cgi-bin/menu/create?access_token=
2：新增素材：https://api.weixin.qq.com/cgi-bin/media/upload?access_token=
3：微信支付：https://api.mch.weixin.qq.com/pay/unifiedorder
4：二维码生成:https://api.weixin.qq.com/cgi-bin/qrcode/create?access_token=
以上的 url 全部都只使用了 GET、POST 两种请求类型，并且对资源的操作类似于 upload、create 都放在了 url 之中，所以无论是在逻辑上，还是在实践中Roy Fielding 博士的 restful url 仅为一个学术化上的建议，并不适合用于实践
综上，jfinal 在资源抽象这个核心问题上认同 restful架构风格，但对其建议的 url 风格持高度怀疑态度
2017-03-19 17:43
通常希望通过希望页号 pageNumber 与 pageSize 这两个参数获取数据的需求更多，也更直观，offset limit 这两个参数在本质上与 pageSize 和 pageNumber 是等价的，可以通过计算去互相转换，所以更多是从需求强烈程度去考虑这个设计
当然 offset limit 这个需求可能也是存在的，至少从这几年实践的角度来看，需求并不强烈
未来是否提供 start 和 end 分页接口取决于需求的强烈程度，目前是建议通过 baseModel 去扩展，因为只需要将 offset limit 计算转换成 pageNumber、pageSize 就可以重用现在已有的 API 去实现功能
2017-03-19 17:34
jfinal demo 这个 demo 至少有三年没动过了，一直是正常的，肯定是可以的，再多试试
2017-03-19 17:31
由于 jfinal 开源已有五年多了，所以很多老用户和老项目还在用 jdk 1.6，为了照顾老用户和兼容老项目，最远可以支持 jdk 1.6，所以 jfinal 项目自身的代码通程没有使用 lambda 表达式
现要只能是大家可以在自己的基于 jfinal 的项目中自由使用 lambda，而 jfinal 代码暂时还不能使用 lambda
