2017-03-02 16:48
@longhnbc 考虑以传参的形式来传递样式、html 等数据,如果这样做不划算,或许没有必要去封装,因为可重用性是封装的重要原因,而可重用性是基于有东西被重复的假设
当所有的东西都是动态的,相当于没啥在重复,也就没有必要封装了
2017-03-02 16:17
@gaurder 用自定义指令、sharedMethod 、sharedObject 三种扩展方式都可以很容易去解决,参考一下 #date 指令的实现方式
2017-03-02 16:08
find(getSql("findPrettyGirl"), 16, 23) 这行代码是在 model 中使用的范例,只有一个参数,但另一个参数就是该 model 中存放属性值的那个 map
所以,Model.getSql(...) 虽然只有一个参数,但第二个参数其实是自身的属性 map,而 Db.getSql(...) 由于与 model、record 是脱离的,所以必须要提供第二个参数
JMap.create("age",18).put("weight",50); 这行代码是手误,链式调用需要将 put 改为 set 才可以,感谢你的反馈,现已对该错误进行了改正
jfinal 手册新添加的 sql 管理部分是在春节前通宵赶出来的,有一些内容缺失,也有手误,再次感谢你的反馈
2017-03-02 12:38
@lyh061619 感谢回复
有异常一定会在控制台输出的,而且页面也会输出 404 或 500 错误,sql 语句也可以通过配置来输出。将异常输出在页面会让黑客有可乘之机,黑客可以有计划的去制造异常,然后通过页面的异常分析并得到系统的漏洞
当然,提供这个输出异常到页面的功能,也可以让开发者通过配置在生产环境之下关闭,但也难保有时会忘了关闭或者其它的失误
2017-03-01 17:32
@vikingSun 第一个问题,sql 管理功能有她合适的场景,例如,做跨数据库的产品,如果 sql 写在外部文件中,可以为不同的数据库分别去写一套,从而实现跨数据库的功能。此外写在外部 sql 文件之中,还有助于一些大公司的 DBA 职位,他们的 sql 是 DBA 来写并不断优化的,写在外部方便随时查看并根据 sql 性能监控的结果做优化。
对于其它很多情况,其一是基本的 CRUD 中的 CUD 都已被 jfinal 实现过了,其二是可以直接在 java 中写 sql,确实没有必要使用外部文件进行管理,这也是 jfinal 在相当长的时间并没有提供外部 sql 管理功能的重大原因
第二个问题,让开发者发挥想象力,各显神通就好,jfinal 作为框架,更好地是去实现基础设施性的功能,这样才能降低学习成本,保持极简风格
第三个问题,与第二个问题类似的原因,jfinal 目前只实现基础功能,以免事情变得复杂。扫描 sql 文件这件事情,说大不大,但要做得很完善,尤其是要做成极简,也得费一番事,例如,得考虑扫描什么类型的文件,是不是要分析文件内容来确定是 sql 文件等等