2017-03-20 21:03
@广州雨人 参考一下这些博文:https://www.oschina.net/search?scope=blog&q=jfinal%20dubbo
2017-03-20 19:33
有了对比，才会在认知上更有深度，spring 由于过于繁琐庞大、过度设计、配置文件满天飞，所以才会出现 spring boot 这个项目给 spring 做简化工作，而 spring boot 中的很多功能 jfinal 早在五年前就有了，例如零配置、java config 这类概念、热加载，减少代码量等等设计目标
spring boot 本质上是在重走 jfinal 五年之前就开始走的路，但是 spring boot 底层仍然基于 spring 这个庞然大物，开发者看到的仅是浮出海面的冰山，而隐藏在海水之下的山体才是更大的麻烦，所以很多 spring boot 用户在开发过程中会不断要去学习 spring 有关的概念
jfinal 是极简设计，学习成本极低，WEB MVC + ORM + Template Engine 所有功能仅有 400K 左右的 jar 包，比 spring 体系要小得多，所以无论大家是否想用 jfinal 开发，掌握 jfinal 都是很容易并且值得的
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 至少有三年没动过了，一直是正常的，肯定是可以的，再多试试
